500 पंक्तियों में अपना खुद का टाइपसेफ रिएक्ट राउटर कैसे लिखें

लगभग 6 साल पहले जब मैं रिएक्ट सीख रहा था, तो रिएक्ट-राउटर मेरे द्वारा चुनी गई पहली तृतीय-पक्ष लाइब्रेरी में से एक थी। मेरा मतलब है, यह समझ में आता है: रूटिंग आधुनिक सिंगल पेज एप्लिकेशन के प्रमुख पहलुओं में से एक है। मैंने इसे हल्के में लिया. मेरे लिए, रिएक्ट-राउटर एक जादू का पिटारा था, मुझे नहीं पता था कि यह आंतरिक रूप से कैसे काम करता है। इसलिए, जब कुछ समय बाद मुझे स्वाभाविक रूप से पता चला कि रूटिंग सामान्य रूप से कैसे काम करती है, तो यह थोड़ा दुखद था। अब कोई जादू नहीं, हुह :( लेकिन मुझे खुशी है कि मैंने "जादुई ब्लैक बॉक्स" की अवधारणा को पीछे छोड़ दिया। मुझे लगता है कि यह सचमुच हानिकारक विचार है। यह समझना कि तकनीक का टुकड़ा आपके और मेरे जैसे इंजीनियरों द्वारा बनाया गया है, मुझे बहुत प्रेरित करता है, और मुझे आशा है कि यह आपके लिए भी ऐसा ही करेगा। हर तो, इस पोस्ट में मेरे साथ शामिल हों जहां हम उस ब्लैक बॉक्स को खोलने और उसके आंतरिक कामकाज को समझने के लिए स्क्रैच से अपना खुद का टाइपसेफ राउटर बनाएंगे। यह आलेख मानता है कि आप पहले से ही रिएक्ट जानते हैं और टाइपस्क्रिप्ट के साथ सहज हैं। विशेषताएँ एवं सीमाएँ आइए मैं बताता हूं कि इस लेख में हमारे राउटर की कौन सी विशेषताएं शामिल की जाएंगी। हमारा किलर फीचर टाइपसेफ्टी होगा। इसका मतलब है कि आपको अपने मार्गों को पहले से परिभाषित करने की आवश्यकता होगी और टाइपस्क्रिप्ट जांच करेगा कि आप यूआरएल के बजाय कुछ बकवास पास नहीं कर रहे हैं या वर्तमान मार्ग में गायब पैरामीटर प्राप्त करने का प्रयास नहीं कर रहे हैं। इसके लिए कुछ प्रकार के जिम्नास्टिक की आवश्यकता होगी, लेकिन चिंता न करें, मैं आपको बताऊंगा। इसके अलावा, हमारा राउटर उन सभी चीजों का समर्थन करेगा जो आप एक औसत राउटर से उम्मीद करते हैं: यूआरएल पर नेविगेशन, रूट मिलान, रूट पैरामीटर पार्सिंग, बैक/फॉरवर्ड नेविगेशन और नेविगेशन ब्लॉकिंग। अब, सीमाओं के बारे में। हमारा राउटर केवल ब्राउज़र में काम करेगा (क्षमा करें रिएक्ट नेटिव!), और यह एसआरआर का समर्थन नहीं करेगा। एसएसआर समर्थन अपेक्षाकृत आसान होना चाहिए, लेकिन यह पोस्ट पहले से ही बहुत बड़ी है, इसलिए मैं इसे कवर नहीं करूंगा। शब्दावली अब जब हमारे पास एक दृष्टिकोण है कि हम क्या बनाना चाहते हैं, तो हमें संरचना और शब्दावली के बारे में बात करने की ज़रूरत है। बहुत सारी समान अवधारणाएँ होंगी, इसलिए उन्हें पहले से परिभाषित करना महत्वपूर्ण है। हमारी लाइब्रेरी में दो प्रकार के मार्ग होंगे: कच्चे मार्ग और पार्स किए गए मार्ग। केवल एक स्ट्रिंग है जो या जैसा दिखता है; यह यूआरएल के लिए एक टेम्पलेट है. कच्चे रूट में पैरामीटर हो सकते हैं, जो ऐसे अनुभाग हैं जो कोलन से शुरू होते हैं, जैसे । कच्चा मार्ग /user/:id/info /login :id यह प्रारूप डेवलपर्स के लिए उपयोग करना आसान है, लेकिन किसी प्रोग्राम के लिए इतना आसान नहीं है; हम उन मार्गों को अधिक मशीन-अनुकूल प्रारूप में बदल देंगे और इसे कहेंगे। पार्स्ड मार्ग लेकिन उपयोगकर्ता रूट नहीं खोलते, वे यूआरएल खोलते हैं। और यूआरएल संसाधन के लिए एक पहचानकर्ता है (हमारे मामले में ऐप के अंदर का पेज); यह जैसा दिख सकता है। हमारा राउटर अधिकतर URL के दूसरे भाग ( ) की परवाह करता है, जिसे हम कहेंगे। http://example.app/user/42/info?anonymous=1#bio /user/42/info?anonymous=1#bio path पथ में ( ), ( ) और ( ) शामिल हैं। वह ऑब्जेक्ट जो उन घटकों को अलग-अलग फ़ील्ड के रूप में संग्रहीत करता है उसे कहा जाएगा। पथनाम /user/42/info खोज पैरामीटर ?anonymous=1 हैश #bio स्थान एपीआई का उच्च स्तरीय अवलोकन रिएक्ट लाइब्रेरी बनाते समय, मैं तीन चरणों में जाना पसंद करता हूँ। सबसे पहले, अनिवार्य एपीआई। इसके कार्यों को किसी भी स्थान से बुलाया जा सकता है, और वे आमतौर पर रिएक्ट से बिल्कुल भी बंधे नहीं होते हैं। राउटर के मामले में, यह , या जैसे कार्य होंगे। navigate getLocation subscribe फिर, उन कार्यों के आधार पर, या जैसे हुक बनाए जाते हैं। और फिर उन कार्यों और हुकों का उपयोग घटकों के निर्माण के लिए आधार के रूप में किया जाता है। मेरे अनुभव में यह असाधारण रूप से अच्छी तरह से काम करता है, और आसानी से विस्तार योग्य और बहुमुखी पुस्तकालय बनाने की अनुमति देता है। useLocation useCurrentRoute राउटर का एपीआई फ़ंक्शन से शुरू होता है। उपयोगकर्ता को फ़ंक्शन में सभी कच्चे मार्गों का एक नक्शा पास करना होता है, जो मार्गों को पार्स करता है और उसी आकार के साथ मैपिंग लौटाता है। सभी डेवलपर-सामना वाले एपीआई, जैसे यूआरएल जेनरेशन या रूट मिलान, पार्स किए गए रूट स्वीकार करेंगे, कच्चे नहीं। defineRoutes const routes = defineRoutes({ login: '/login', user: { me: '/user/me', byId: '/user/:id/info', } }); अगला कदम पार्स किए गए मार्गों को फ़ंक्शन में पास करना है। यह हमारे राउटर का मांस है। यह फ़ंक्शन सभी फ़ंक्शन, हुक और घटक बनाएगा। यह असामान्य लग सकता है, लेकिन ऐसी संरचना हमें स्वीकृत तर्कों और प्रॉप्स के प्रकारों को में परिभाषित के एक विशिष्ट सेट के अनुरूप बनाने की अनुमति देती है, जिससे प्रकार की सुरक्षा सुनिश्चित होती है (और डीएक्स में सुधार होता है)। createRouter routes const { Link, Route, useCurrentRoute, navigate, /* etc... */ } = createRouter(routes); उन फ़ंक्शंस को लौटाएगा जिनका उपयोग आपके ऐप में कहीं भी किया जा सकता है (अनिवार्य एपीआई), हुक जो आपके घटकों को स्थान परिवर्तनों पर प्रतिक्रिया करने की अनुमति देते हैं, और तीन घटक: , और । यह अधिकांश उपयोग के मामलों को कवर करने के लिए पर्याप्त होगा, और आप उन एपीआई के आधार पर अपने स्वयं के घटक बना सकते हैं। createRouter Link Route NotFound मौज-मस्ती और लाभ के लिए टाइप-लेवल प्रोग्रामिंग हम अपनी पिच के टाइपसेफ्टी भाग से निपटने से शुरुआत करते हैं। जैसा कि मैंने पहले उल्लेख किया है, टाइपसेफ राउटर के साथ, टाइपस्क्रिप्ट आपको इस तरह की स्थिति के बारे में पहले से चेतावनी देगा: या इस तरह: const { userld } = useRoute(routes.user.byId); और यदि आप तुरंत नहीं देख पा रहे हैं कि इनमें क्या खराबी है, तो आपको निश्चित रूप से एक टाइपसेफ राउटर की आवश्यकता है :) टाइपस्क्रिप्ट में टाइप सिस्टम बहुत शक्तिशाली है। मेरा मतलब है, आप टाइप-लेवल प्रोग्रामिंग का उपयोग करके एक , एक या यहां तक कि एक भी बना सकते हैं। शतरंज इंजन साहसिक गेम SQL डेटाबेस आप पहले से ही 'मूल्य-स्तरीय प्रोग्रामिंग' से परिचित हैं जहां आप मूल्यों में हेरफेर करते हैं, उदाहरण के लिए, दो तारों को जोड़ना: function concat(a, b) { return a + b; } concat('Hello, ', 'World!'); // 'Hello, World!' लेकिन आप इसे प्रकारों के साथ भी कर सकते हैं! type Concat = `${A}${B}`; type X = Concat ; // ^? type X = "Hello, World!" हां, यह आपके सामान्य कार्यों जितना शक्तिशाली नहीं है और अलग दिखता है। लेकिन यह आपको कुछ बहुत बढ़िया और उपयोगी चीज़ें करने की अनुमति देता है। हम कच्चे मार्गों से पैरामीटर निकालने और नए प्रकार बनाने के लिए टाइप-स्तरीय प्रोग्रामिंग का उपयोग करेंगे जो जांच कर सकते हैं कि डेवलपर या यूआरएल का निर्माण करने वाले फ़ंक्शन में गलत मान पास करने का प्रयास नहीं करता है। Link टीएस के साथ टाइप-स्तरीय प्रोग्रामिंग शीघ्र ही एक अपठनीय गड़बड़ी बन सकती है। हमारे लिए सौभाग्य से, पहले से ही कई परियोजनाएं हैं जो इस सारी जटिलता को छिपा देती हैं और हमें इस तरह से साफ कोड लिखने की अनुमति देती हैं: export type RouteParam = Pipe , Tuples.Filter >, Tuples.Map >, Tuples.ToUnion ] >; बहुत साफ-सुथरा, हुह? वैसे, कच्चे मार्ग से मापदंडों को पार्स करने के लिए आपको बस यही कोड चाहिए होता है। इस प्रोजेक्ट में, हम लाइब्रेरी का उपयोग करेंगे - यह हमें जटिलता और टाइप-स्तरीय कोड की मात्रा को कम करने में मदद करेगी। हॉटस्क्रिप्ट लेकिन इसकी आवश्यकता नहीं है: यदि आप साहसी महसूस करते हैं, तो आप इन सभी प्रकारों को स्वयं लागू करने का प्रयास कर सकते हैं। आप में कुछ प्रेरणा पा सकते हैं, जो तृतीय-पक्ष प्रकार की लाइब्रेरी का उपयोग किए बिना समान सुविधाओं को लागू करता है। चिकेन राउटर यदि आप अनुसरण करना चाहते हैं, तो मेरा सुझाव है कि आप अपने पसंदीदा स्टार्टर (मैं का उपयोग करता हूं) का उपयोग करके एक नया रिएक्ट प्रोजेक्ट बनाएं और वहां कोडिंग शुरू करें। इस तरह, आप तुरंत अपने राउटर का परीक्षण कर पाएंगे। Vite कृपया ध्यान दें कि नेक्स्ट.जेएस जैसे फ्रेमवर्क अपनी स्वयं की रूटिंग प्रदान करते हैं जो इस प्रोजेक्ट में हस्तक्षेप कर सकते हैं, और इसके बजाय 'वेनिला' रिएक्ट का उपयोग करते हैं। यदि आपको कोई कठिनाई है, तो आप पूरा कोड पा सकते हैं। यहां तृतीय-पक्ष पैकेज स्थापित करके प्रारंभ करें: टाइप-स्तरीय उपयोगिताओं के लिए और URL/रॉ रूट से पैरामीटर पार्स करने के लिए । हॉटस्क्रिप्ट regexparam npm install hotscript regexparam हमारे प्रकार की पहली इमारत ईंट कच्चा मार्ग है। कच्चा मार्ग से शुरू होना चाहिए; आप इसे टीएस में कैसे कोड करेंगे? इस कदर: / export type RawRoute = `/${string}`; आसान, है ना? लेकिन एक भी कच्चे मार्ग को स्वीकार नहीं करता है, यह मैपिंग को स्वीकार करता है, संभवतः नेस्टेड, तो चलिए इसे कोड करते हैं। हो सकता है कि आप ऐसा कुछ लिखने के लिए प्रलोभित हों: defineRoutes export type RawRoutesMap = { [key: string]: RawRoute | RawRoutesMap }; ये काम करेगा. हालाँकि, यह प्रकार असीम रूप से गहरा हो सकता है, और कुछ मामलों में टीएस को इसकी गणना करने में कठिनाई होगी। टीएस के जीवन को आसान बनाने के लिए, हम अनुमत घोंसले के स्तर को सीमित करेंगे। सभी ऐप्स के लिए 20 नेस्टिंग स्तर पर्याप्त होने चाहिए और टीएस इसे आसानी से संभाल सकता है। लेकिन आप पुनरावर्ती प्रकारों की गहराई को कैसे सीमित करते हैं? मैंने यह युक्ति इस से सीखी; यहां हमारी आवश्यकताओं के लिए संशोधित संस्करण दिया गया है: SO उत्तर export type RecursiveMap = { [key: string]: RecursiveMap_ ; }; type RecursiveMap_ = MaxDepth extends Stack["length"] ? T : T | { [key: string]: RecursiveMap_ }; यह हमारा पहला जटिल प्रकार है, इसलिए मैं इसे समझाता हूँ। हमारे यहां दो प्रकार हैं: एक प्रवेश बिंदु के रूप में काम करता है और इसे एक अतिरिक्त टपल पैरामीटर पास करते हुए कॉल करता है। इस टपल का उपयोग मैपिंग की गहराई को ट्रैक करने के लिए किया जाता है, प्रत्येक कॉल के साथ हम इस सरणी में एक तत्व जोड़ते हैं। RecursiveMap RecursiveMap_ और हम इसे तब तक कॉल करना जारी रखते हैं जब तक कि इस टुपल की लंबाई के बराबर न हो जाए। टीएस में, जब उपयोग मानों के साथ किया जाता है, जिसे शाब्दिक भी कहा जाता है (उदाहरण के लिए, विशेष रूप से , नहीं), तो इसका अर्थ 'बराबर' है। MaxDepth extends विशिष्ट 42 number और चूंकि और दोनों विशिष्ट संख्याएं हैं, इसलिए इस कोड को के रूप में पढ़ा जा सकता है। इस कंस्ट्रक्शन का इस्तेमाल आप खूब देखेंगे. MaxDepth Stack["length"] MaxDepth === Stack["length"] केवल संख्याएँ जोड़ने के बजाय टुपल का उपयोग क्यों करें? खैर, टाइपस्क्रिप्ट में दो नंबर जोड़ना इतना आसान नहीं है! इसके लिए है, और हॉटस्क्रिप्ट नंबर भी जोड़ सकता है, लेकिन इसके लिए बहुत सारे कोड की आवश्यकता होती है (भले ही आप इसे न देखें), जो अत्यधिक उपयोग किए जाने पर आपके टीएस सर्वर और कोड संपादक को धीमा कर सकता है। एक पूरी लाइब्रेरी इसलिए, मेरे अंगूठे का नियम यह है कि जितना संभव हो सके जटिल प्रकारों से बचें। इस उपयोगिता प्रकार के साथ, हम अपनी मैपिंग को सरलता से परिभाषित कर सकते हैं: export type RawRoutesMap = RecursiveMap ; कच्चे मार्ग प्रकारों के लिए बस इतना ही। कतार में अगला पार्स किया गया मार्ग है। पार्स किया गया मार्ग कुछ अतिरिक्त फ़ील्ड और एक फ़ंक्शन के साथ केवल एक जावास्क्रिप्ट ऑब्जेक्ट है; यह इस प्रकार दिखता है: export type ParsedRoute = { keys: RouteParam []; build(...params: PathConstructorParams ): Path ; raw: R; ambiguousness: number, pattern: RegExp; }; आइए फ़ील्ड से इसे अनपैक करना शुरू करें। यह बस मापदंडों की एक श्रृंखला है जो इस मार्ग के लिए आवश्यक है। यहां बताया गया है कि यह कैसे किया जाता है: keys import { Pipe, Strings, Tuples } from "hotscript"; export type RouteParam = Pipe , Tuples.Filter >, Tuples.Map >, Tuples.ToUnion ] >; हॉटस्क्रिप्ट में, किसी फ़ंक्शन को कॉल करने के दो तरीके हैं: या । तब उपयोगी होती है जब आपको किसी एकल फ़ंक्शन को कॉल करने की आवश्यकता होती है, लेकिन हमारे मामले में, हमारे पास उनमें से 4 हैं! इनपुट स्वीकार करता है और, इसे दिए गए टपल के पहले फ़ंक्शन में पाइप करता है। Call Pipe Call Pipe लौटाया गया मान दूसरे फ़ंक्शन में इनपुट के रूप में पास किया जाता है इत्यादि। हमारे मामले में, उदाहरण के लिए, यदि हमारे पास कच्चा मार्ग होता, तो इसे इस तरह रूपांतरित किया जाता: /user/:userId/posts/:postId export type Beep = Pipe , // ["user", ":userId", "posts", ":postId"] Tuples.Filter >, // [":userId", ":postId"] Tuples.Map >, // ["userId", "postId"] Tuples.ToUnion // "userId" | "postId" ] >; देखना? यह टाइप-लेवल प्रोग्रामिंग का जादू है! अब, आइए उस फ़ंक्शन से निपटें। यह रूट पैरामीटर (जैसे और ) और वैकल्पिक खोज पैरामीटर/हैश स्वीकार करता है, और उन्हें एक पथ में जोड़ता है। कार्यान्वयन पर एक नज़र डालें: build userId postId PathConstructorParams // Allows us to also accept number and // any other type which can be converted into string export type StringLike = { toString: () => string }; export type SearchAndHashPathConstructorParams = { hash?: string, search?: string | { [key: string]: string, } }; export type RouteParamsMap = { [key in RouteParam ]: Val }; export type PathConstructorParams = | [RouteParamsMap ] | [RouteParamsMap , SearchAndHashPathConstructorParams]; फ़ंक्शन पैरामीटर को एक सरणी के रूप में परिभाषित किया गया है (जिसे बाद में ... की परिभाषा में फैलाया गया है फ़ंक्शन), जहां पहला तत्व है और दूसरा वैकल्पिक है। का मूल्य लौटाने के बारे में क्या? हमने इसका पथ पहले ही स्थापित कर लिया है, लेकिन आप टाइपस्क्रिप्ट के साथ इसका वर्णन कैसे करते हैं? build RouteParamsMap SearchAndHashPathConstructorParams build खैर, यह काफी हद तक के समान है, लेकिन इसके लिए कुछ अधिक प्रकार के जिम्नास्टिक की आवश्यकता होती है! RouteParam import { Fn } from "hotscript"; interface ReplaceParam extends Fn { return: this["arg0"] extends `:${string}` ? string : this["arg0"]; } // Leading slashes will be removed by Split , so we need to // add them back after our manipulations type Pathname = `/${Pipe , Tuples.Map , Tuples.Join ] >}${Route extends `${string}/` ? '/' : ''}`; export type Path = Pathname | `${Pathname }?${string}` | `${Pathname }#${string}`; हम यहां अपने मार्ग को खंडों में विभाजित करते हैं, प्रत्येक खंड पर मानचित्र बनाते हैं, और प्रत्येक पर अपने कस्टम फ़ंक्शन कॉल करते हैं। यह जाँचता है कि क्या वर्तमान खंड एक पैरामीटर है और इसे से बदल देता है या खंड को वैसे ही लौटा देता है। 'फ़ंक्शन' थोड़ा अजीब लग सकता है, लेकिन हॉटस्क्रिप्ट के साथ आप कस्टम फ़ंक्शंस को इसी तरह परिभाषित करते हैं। ReplaceParam string ReplaceParam हम स्पष्ट रूप से बताते हैं कि पथ में या तो सिर्फ पथ शामिल है, पथ के बाद एक प्रश्न चिह्न होता है (यह खोज पैरामीटर और हैश के साथ यूआरएल को कवर करता है), या एक हैश प्रतीक (यह खोज पैरामीटर के बिना लेकिन हैश के साथ यूआरएल को कवर करता है)। हमें मिलान किए गए मार्ग का वर्णन करने के लिए एक प्रकार की भी आवश्यकता होगी, यानी, यूआरएल से कैप्चर किए गए पैरामीटर के साथ पार्स किया गया मार्ग: // Interface (and not type) because we need to use `this` export interface RouteWithParams { route: ParsedRoute , params: RouteParamsMap , // TS can't properly infer type of route object with simple // check like currentRoute.route === routes.user.byId, so we // need our custom type guard matches: (route: ParsedRoute ) => this is RouteWithParams , } अंतिम प्रकार है; यह के समान है, लेकिन, अच्छी तरह से, पार्स किए गए मार्गों के लिए है। ParsedRoutesMap RawRoutesMap // This accepts RawRoutesMap and transforms it into // mapping of parsed routes of same shape export type ParsedRoutesMap = { [Key in keyof RM]: RM[Key] extends RawRoute ? ParsedRoute : RM[Key] extends RawRoutesMap ? ParsedRoutesMap : never; }; और उस नोट पर, हम प्रकारों के साथ समाप्त करते हैं। कुछ और भी होंगे, लेकिन वे सरल हैं, और जैसे-जैसे हम कार्यान्वयन के साथ आगे बढ़ेंगे, हम उन्हें कवर करेंगे। यदि टाइप-लेवल प्रोग्रामिंग ऐसी चीज़ है जिसे आप और अधिक आज़माना चाहेंगे, तो आप अधिक जानने के लिए देख सकते हैं और हल करने का प्रयास कर सकते हैं (उनके पास भी है)। टाइप-लेवल टाइपस्क्रिप्ट टाइप-चुनौतियों को संसाधनों की एक अच्छी सूची रूट पार्सर अंततः, हम नियमित मूल्य-स्तरीय कोडिंग पर वापस आ गए हैं। आइए लागू करके शुरुआत करें। defineRoutes export const typedKeys = (obj: T) => { return Object.keys(obj) as Array ; }; export const defineRoutes = (routesMap: T): ParsedRoutesMap => { const entries = typedKeys(routesMap).map((key) => { const entry = routesMap[key]; if (typeof entry === 'string') { return [key, parseRoute(entry)] as const; } else { // Nested map return [key, defineRoutes(entry)] as const; } }); return Object.fromEntries(entries); }; यहां कुछ भी जटिल नहीं है; आइए फ़ंक्शन के बारे में गहराई से जानें। parseRoute import { parse, inject, type RouteParams as RegexRouteParams } from "regexparam"; export class InvalidRoute extends Error { }; export class InvalidRouteParams extends Error { }; const parseRoute = (route: R): ParsedRoute => { if (!route.startsWith('/')) { throw new InvalidRoute('route should start with slash (/)') } const { keys, pattern } = parse(route); const hasRequiredParams = keys.length > 0; const parsedRoute: ParsedRoute = { build(...args) { const params = ( hasRequiredParams ? args[0] : undefined ) as RouteParamsMap | undefined; const searchAndHash = ( hasRequiredParams ? args[1] : args[0] ) as SearchAndHashPathConstructorParams | undefined; if (hasRequiredParams) { if (!params) { throw new InvalidRouteParams( `Parameters for route ${route} weren't provided` ); } const missingKeys = keys.filter(k => !(k in params)); if (missingKeys.length) { throw new InvalidRouteParams( `Missing parameters for route ${route}: ${missingKeys.join(', ')}` ); } } else if (args.length > 1) { throw new InvalidRouteParams( `Route ${route} doesn't accept any parameters, received ${args[0]}` ); } let path = hasRequiredParams ? inject(route, params as RegexRouteParams ) : route; if (searchAndHash && searchAndHash.search) { if (typeof searchAndHash.search === 'string') { path += searchAndHash.search.startsWith('?') ? searchAndHash.search : '?' + searchAndHash.search; } else { path += '?' + new URLSearchParams(searchAndHash.search).toString(); } } if (searchAndHash && searchAndHash.hash) { path += searchAndHash.hash.startsWith('#') ? searchAndHash.hash : '#' + searchAndHash.hash; } return path as Path ; }, raw: route, keys: keys as RouteParam [] || [], ambiguousness: keys.length, pattern: pattern, }; return parsedRoute; }; भी बहुत सरल है, यद्यपि काफी लंबा है। रूट को पार्स करने और पैरामीटर निकालने के लिए, हम लाइब्रेरी का उपयोग करते हैं। यह हमें रूट के लिए आवश्यक मापदंडों की एक श्रृंखला प्राप्त करने की अनुमति देता है और एक नियमित अभिव्यक्ति उत्पन्न करता है जिसे हम बाद में रूट के साथ यूआरएल से मिलान करने के लिए उपयोग करेंगे। parseRoute regexparam हम इस जानकारी को इस ऑब्जेक्ट के निर्माण के लिए उपयोग किए गए मूल कच्चे मार्ग और अस्पष्टता स्तर (जो मार्ग में केवल कई पैरामीटर हैं) के साथ संग्रहीत करते हैं। इतिहास आवरण प्रत्येक राउटर को अपना स्टेट कहीं न कहीं स्टोर करना होता है। ब्राउज़र में ऐप्स के मामले में, यह वास्तव में 4 विकल्पों तक सीमित हो जाता है: इन-मेमोरी (या तो रूट घटक के अंदर एक राज्य चर में या घटकों के पेड़ के बाहर एक चर में), इतिहास एपीआई, या यूआरएल का हैश भाग। यदि आप उपयोगकर्ता को बिल्कुल भी रूट नहीं दिखाना चाहते हैं, तो इन-मेमोरी रूटिंग आपकी पसंद हो सकती है, उदाहरण के लिए, यदि आप रिएक्ट में एक गेम को कोड कर रहे हैं। रूट को हैश में संग्रहीत करना तब आसान हो सकता है जब आपका रिएक्ट ऐप एक बड़े एप्लिकेशन में केवल एक पृष्ठ हो, और आप यूआरएल को अपनी इच्छानुसार नहीं बदल सकते। लेकिन अधिकांश मामलों के लिए, हिस्ट्री एपीआई का उपयोग करना सबसे अच्छा विकल्प होगा। यह एसएसआर के साथ संगत है (अन्य विकल्प नहीं हैं), उपयोगकर्ता के आदी व्यवहार पैटर्न का पालन करता है, और बिल्कुल साफ दिखता है। इस परियोजना में, हम इसका भी उपयोग करेंगे। हालाँकि इसमें एक उल्लेखनीय दोष है: अतिरिक्त रैपर के बिना यह अधिकतर अनुपयोगी है। हिस्ट्री एपी के साथ, आप इवेंट की सदस्यता ले सकते हैं, और यूआरएल बदलने पर ब्राउज़र आपको बताएगा। लेकिन केवल तभी जब परिवर्तन उपयोगकर्ता द्वारा शुरू किया गया हो, उदाहरण के लिए, बैक बटन पर क्लिक करके। यदि कोई यूआरएल परिवर्तन कोड से शुरू किया गया है, तो आपको स्वयं इसका ट्रैक रखना होगा। popstate जिन राउटर्स का मैंने अध्ययन किया उनमें से अधिकांश अपने स्वयं के रैपर का उपयोग करते हैं: रिएक्ट-राउटर और चिकेन एनपीएम पैकेज का उपयोग करते हैं, टैनस्टैक राउटर का है और राउटर में पूर्ण-फ्लेजर रैपर नहीं है लेकिन फिर भी इसे करना पड़ता है। इतिहास अपना कार्यान्वयन मंकी-पैच इतिहास तो, आइए अपना खुद का रैपर लागू करें। export type HistoryLocation = Pick ; export type NavigationBlocker = (isSoftNavigation: boolean) => boolean; export const createHistory = () => { const winHistory = window.history; const winLocation = window.location; const getLocation = (): HistoryLocation => { return { origin: winLocation.origin, href: winLocation.href, pathname: winLocation.pathname, search: winLocation.search, hash: winLocation.hash, }; }; /* Some magic code */ return /* something... */; }; हम दो प्रकार का उपयोग करेंगे, और । पहला, अंतर्निहित प्रकार का थोड़ा सीमित संस्करण है (यह का प्रकार है), और दूसरा, नेविगेशन अवरोधन पर पहुंचने के बाद इसे कवर किया जाएगा। इस अध्याय के सभी आगे के कोड फ़ंक्शन के अंदर जाएंगे। HistoryLocation NavigationBlocker Location window.location createHistory आइए इतिहास में बदलावों की सदस्यता लागू करने से शुरुआत करें। हम इस प्रोजेक्ट में सदस्यता लेने के लिए रिएक्ट-शैली फ़ंक्शंस का उपयोग करेंगे: आप कॉलबैक पास करके कॉल करते हैं, और यह एक अन्य फ़ंक्शन लौटाता है जिसे आपको तब कॉल करने की आवश्यकता होती है जब आप सदस्यता समाप्त करना चाहते हैं। subscribe const subscribers: Set = new Set(); const onChange = () => { subscribers.forEach(fn => { try { fn(); } catch (err) { console.error('Error while handling location update', err); } }) }; const subscribe = (listener: VoidFunction) => { subscribers.add(listener); return () => { subscribers.delete(listener); }; }; अगला कदम स्थान परिवर्तन पर प्रतिक्रिया देना है, जिसमें प्रोग्रामेटिक रूप से किए गए परिवर्तन भी शामिल हैं। आपको इसे कैसे करना होगा? बेशक, के साथ। यह थोड़ा गंदा लग सकता है (और यह वास्तव में है), लेकिन दुर्भाग्य से हमारे पास बेहतर विकल्प नहीं हैं। बंदर-पैचिंग const origPushState = winHistory.pushState.bind(winHistory); const origReplaceState = winHistory.replaceState.bind(winHistory); winHistory.pushState = (data, unused, url) => { // tryNavigate will be covered later tryNavigate(() => { origPushState(data, unused, url); onChange(); }); }; winHistory.replaceState = (data, unused, url) => { tryNavigate(() => { origReplaceState(data, unused, url); onChange(); }); }; // This event is emmited when user initiates navigation // or when calling history.go, history.back and history.forward window.addEventListener('popstate', onChange); और हमारे इतिहास के कार्यान्वयन में आखिरी प्रमुख गायब हिस्सा नेविगेशन ब्लॉकिंग है: एक सुविधा जो आपको नेविगेशन अनुरोध को रोकने और इसे सशर्त रूप से रद्द करने की अनुमति देती है। नेविगेशन ब्लॉकिंग का एक कैनन उदाहरण उपयोगकर्ता को एक फॉर्म में अपनी प्रगति खोने से रोकेगा। let blockers: NavigationBlocker[] = []; const beforeUnloadHandler = (event: Event) => { const blocked = blockers.some(blocker => blocker(false)); if (blocked) { event.preventDefault(); // @ts-ignore For older browsers event.returnValue = ''; return ''; } }; const tryNavigate = (cb: VoidFunction) => { const blocked = blockers.some(blocker => blocker(true)); if (blocked) return; cb(); }; const addBlocker = (blocker: NavigationBlocker) => { blockers.push(blocker); if (blockers.length === 1) { addEventListener('beforeunload', beforeUnloadHandler, { capture: true }); } return () => { blockers = blockers.filter(b => b !== blocker); if (blockers.length === 0) { removeEventListener('beforeunload', beforeUnloadHandler, { capture: true }); } } }; हमारे कार्यान्वयन में, अवरोधक एक फ़ंक्शन है जो एक बूलियन लौटाता है जो दर्शाता है कि हमें इस नेविगेशन को अवरुद्ध करने की आवश्यकता है या नहीं। नेविगेशन अवरोधन के संबंध में, नेविगेशन दो प्रकार के होते हैं, और हमें उन्हें अलग-अलग तरीके से संभालने की आवश्यकता होगी। एक ओर, सॉफ्ट नेविगेशन है - जब उपयोगकर्ता हमारे ऐप में एक पेज से दूसरे पेज पर नेविगेट करता है। हम इसे पूरी तरह से नियंत्रित करते हैं और इस प्रकार इसे ब्लॉक कर सकते हैं, कोई भी कस्टम यूआई प्रदर्शित कर सकते हैं (उपयोगकर्ता के इरादे की पुष्टि करने के लिए), या नेविगेशन को ब्लॉक करने के बाद कार्रवाई कर सकते हैं। दूसरी ओर, कठिन नेविगेशन होता है - जब उपयोगकर्ता किसी अन्य साइट पर नेविगेट करता है या टैब पूरी तरह से बंद कर देता है। ब्राउज़र जावास्क्रिप्ट को यह तय करने की अनुमति नहीं दे सकता कि यह नेविगेशन किया जाना चाहिए या नहीं, क्योंकि यह एक सुरक्षा चिंता का विषय होगा। लेकिन ब्राउज़र जावास्क्रिप्ट को यह इंगित करने की अनुमति देता है कि क्या हम उपयोगकर्ता को एक अतिरिक्त पुष्टिकरण संवाद दिखाना चाहते हैं। सॉफ्ट नेविगेशन को ब्लॉक करते समय, आप अतिरिक्त यूआई (उदाहरण के लिए, कस्टम पुष्टिकरण संवाद) प्रदर्शित करना चाह सकते हैं, लेकिन हार्ड नेविगेशन के मामले में, इसका वास्तव में कोई मतलब नहीं है क्योंकि उपयोगकर्ता इसे केवल तभी देख पाएंगे जब वे पेज पर बने रहने का निर्णय लेंगे और , उस समय, यह बेकार और भ्रमित करने वाला है। जब हमारा इतिहास नेविगेशन ब्लॉकर फ़ंक्शन को कॉल करता है, तो यह एक बूलियन प्रदान करेगा, जो दर्शाता है कि हम सॉफ्ट नेविगेशन कर रहे हैं या नहीं। और इन सबके साथ, हमें बस अपना इतिहास ऑब्जेक्ट वापस करना होगा: return { subscribe, getLocation, push: winHistory.pushState, replace: winHistory.replaceState, go: (distance: number) => tryNavigate(() => winHistory.go.call(winHistory, distance)), back: () => tryNavigate(() => winHistory.back.call(winHistory)), forward: () => tryNavigate(() => winHistory.forward.call(winHistory)), addBlocker, }; चरण 1: अनिवार्य एपीआई हम अंततः यहाँ हैं। इंपीरेटिव एपीआई आगे के सभी हुक और घटकों के लिए आधार होगा और डेवलपर को उनकी जरूरतों को पूरा करने के लिए कस्टम हुक बनाने की अनुमति देगा। सबसे पहले, हमें अपने रूट मैप को एक समतल सरणी में बदलने की आवश्यकता है। इस तरह, सभी मार्गों पर लूप करना बहुत आसान हो जाएगा, जो तब काम आएगा जब हम मार्ग-मिलान भाग पर काम करना शुरू करेंगे। हमें दोनों प्रकार की उपयोगिता की आवश्यकता है (जो के संघ में बदल देगा) और फ़ंक्शन (जो पार्स किए गए मार्गों की एक सरणी में बदल देगा)। आइए प्रकार से शुरू करें: ParsedRoutesMap ParsedRoute routesMap export type Values = T[keyof T]; type FlattenRouteMap = T extends ParsedRoute | RawRoute ? T : T extends ParsedRoutesMap | RawRoutesMap ? AllRoutesFromMap : never; export type AllRoutesFromMap | RawRoutesMap > = FlattenRouteMap >; इसे दो प्रकारों में विभाजित करना अनावश्यक लग सकता है, लेकिन इसका एक बहुत ही महत्वपूर्ण कारण है: यदि आप इसे एकल प्रकार के रूप में लागू करते हैं जो स्वयं को कॉल करता है, तो टीएस शिकायत करेगा कि प्रकार अत्यधिक गहरा है और संभवतः अनंत है। इसलिए, हम इसे दो प्रकारों में विभाजित करके काम करते हैं जो एक-दूसरे को बुलाते हैं। मान-स्तरीय फ़ंक्शन के लिए, हमें यह जांचने के लिए एक टाइप गार्ड की भी आवश्यकता होगी कि पारित मान एक पार्स किया गया मार्ग है या नहीं। export const isParsedRoute = ( route: any ): route is ParsedRoute => { return !!route && typeof route === 'object' && typeof route.raw === 'string' && typeof route.build === 'function'; } export const getAllRoutes = ( routesMap: ParsedRoutesMap ): ParsedRoute >[] => { type PossibleRawRoute = AllRoutesFromMap ; return typedKeys(routesMap).flatMap((k) => { const val = routesMap[k]; if (isParsedRoute (val)) { return [val] as const; } // At this point we know that val isn't ParsedRoute, so it has to be map of routes // but TS can't infer that, so we help him a little by casting val to correct type return getAllRoutes(val as ParsedRoutesMap ); }); }; अब, आइए अपने राउटर को लागू करना शुरू करें। इतिहास की तरह, इस और अगले दो अध्यायों में, सभी कोड फ़ंक्शन में जाएंगे, जब तक कि अन्यथा न कहा गया हो। createRouter import { useSyncExternalStore, ComponentType, useMemo, MouseEventHandler, ComponentProps, useEffect } from 'react'; export const createRouter = (routesMap: ParsedRoutesMap ) => { // Type for any possible route from passed routesMap type RouteType = AllRoutesFromMap ; // Similar to above, but for matched routes, ie includes URL parameters type BindedRouteWithParams = RouteWithParams ; // Some of our functions will accept route filter, // which can be single parsed route, array or object type RouteFilter = | ParsedRoute | ParsedRoute [] | Record >; const history = createHistory(); const routes = getAllRoutes(routesMap); }; सबसे पहले, आइए अपने राउटर को वर्तमान स्थान को ज्ञात मार्गों में से किसी एक से मिलाना सिखाएं। कुछ उपयोगिताएँ वैश्विक दायरे या अलग फ़ाइलों में जा सकती हैं, फ़ंक्शन के अंदर नहीं: createRouter export const filterOutFalsy = (obj: T[]): Exclude [] => { return obj.filter(Boolean) as Exclude []; }; export class RouteMatchingConflict extends Error { }; // This will be used later export class RouteMismatch extends Error { }; और यह कोड फ़ंक्शन में चला जाता है। createRouter const extractRouteParams = ( pathname: string, parsedRoute: ParsedRoute ) => { const match = parsedRoute.pattern.exec(pathname); if (!match) return undefined; // Extract all route parameters from match array // and construct object from them return Object.fromEntries(parsedRoute.keys.map((key, index) => { return [key, match[index + 1]]; })) as RouteParamsMap ; }; const findMatchingRoute = ( location: HistoryLocation ): BindedRouteWithParams | undefined => { const matchingRoutes = filterOutFalsy(routes.map(route => { const params = extractRouteParams ( location.pathname, route ); if (!params) return undefined; return { route, params, matches (r: ParsedRoute ) { return route === r; }, }; })); if (matchingRoutes.length === 0) return undefined; if (matchingRoutes.length === 1) return matchingRoutes[0]; // At this point we have multiple matching routes :/ // Gotta decide which one we prefer let lowestAmbiguousnessLevel = Infinity; let lowestAmbiguousnessMatches: BindedRouteWithParams[] = []; matchingRoutes.forEach((match) => { if (match.route.ambiguousness === lowestAmbiguousnessLevel) { lowestAmbiguousnessMatches.push(match); } else if (match.route.ambiguousness m.route.raw).join(', ')}` ); } return lowestAmbiguousnessMatches[0]; }; let currentRoute = findMatchingRoute(history.getLocation()); // This function will be later returned from createRouter function const getCurrentRoute = () => currentRoute; यहां हम सभी ज्ञात मार्गों पर जाते हैं और प्रत्येक को वर्तमान स्थान से मिलाने का प्रयास करते हैं। यदि रूट का रेगेक्स यूआरएल से मेल खाता है - तो हमें यूआरएल से रूट पैरामीटर मिलते हैं, अन्यथा, हमें मिलता है। प्रत्येक मिलान किए गए रूट के लिए, हम एक ऑब्जेक्ट बनाते हैं और इसे एक सरणी में सहेजते हैं। अब, यदि हमारे पास 0 या 1 मिलान मार्ग हैं, तो सब कुछ सरल है। null RouteWithParams हालाँकि, यदि एक से अधिक मार्ग वर्तमान स्थान से मेल खाते हैं, तो हमें यह तय करना होगा कि किसकी प्राथमिकता अधिक है। इसे हल करने के लिए, हम फ़ील्ड का उपयोग करते हैं। जैसा कि आपको याद होगा, इस मार्ग में कई पैरामीटर हैं, और सबसे कम वाले मार्ग को प्राथमिकता दी जाती है। ambiguousness ambiguousness उदाहरण के लिए, यदि हमारे पास दो मार्ग और हैं, तो स्थान दोनों मार्गों से मेल खाएगा। लेकिन यह बिल्कुल स्पष्ट है कि यह यूआरएल रूट के अनुरूप होना चाहिए, न कि अनुरूप। /app/dashboard /app/:section http://example.com/app/dashboard /app/dashboard /app/:section हालाँकि यह एल्गोरिथम बुलेटप्रूफ़ नहीं है। उदाहरण के लिए, रूट और दोनों URL से मेल खाएंगे। और चूंकि उनमें अस्पष्टता का स्तर समान है, इसलिए हमारा राउटर यह तय नहीं कर पाएगा कि किसे प्राथमिकता दी जानी चाहिए। /app/:user/settings/:section /app/dashboard/:section/:region http://example.com/app/dashboard/settings/asia अब, हमें स्थान परिवर्तन पर प्रतिक्रिया करने और वैरिएबल को अपडेट करने के लिए इस कोड को एक साथ चिपकाने की आवश्यकता है; currentRoute const areRoutesEqual = ( a: RouteWithParams | undefined, b: RouteWithParams | undefined ): boolean => { if (!a && !b) return true; // Both are undefined if ((!a && b) || (a && !b)) return false; // Only one is undefined if (!a!.matches(b!.route)) return false; // Different routes // Same routes, but maybe parameters are different? const allParamsMatch = a.route.keys.every(key => a.params[key] === b!.params[key]); return allParamsMatch; }; history.subscribe(() => { const newRoute = findMatchingRoute(history.getLocation()); if (!areRoutesEqual(newRoute, currentRoute)) { currentRoute = newRoute; notifyRouteChange(); // Will be covered later } }); अब, हमारा राउटर स्थान परिवर्तन पर प्रतिक्रिया करता है, और उपयोगकर्ता हमेशा वर्तमान मार्ग प्राप्त कर सकता है, वाह! लेकिन मार्ग परिवर्तन की सदस्यता लेने की क्षमता के बिना यह बहुत उपयोगी नहीं है, तो चलिए इसे जोड़ते हैं। यह दृष्टिकोण बिल्कुल वैसा ही है जैसा हमने इतिहास आवरण में उपयोग किया था। const subscribers: Set = new Set(); const subscribe = (cb: VoidFunction) => { subscribers.add(cb); return () => void subscribers.delete(cb); }; const notifyRouteChange = () => { subscribers.forEach(cb => { try { cb(); } catch (err) { console.error('Error in route change subscriber', err); } }); }; नेविगेशन करने के लिए, हम और फ़ंक्शंस को उजागर करेंगे, जो कि और के चारों ओर एक सरल आवरण है: navigate navigateUnsafe history.push history.replace // This function accepts any string path (no type-safety) const navigateUnsafe = ( path: string, { action = 'push' }: { action?: 'push' | 'replace' } = {} ) => { history[action]({}, '', path) }; // And this function accepts only paths that correspond to one of routes const navigate = ( path: Path , options: { action?: 'push' | 'replace' } = {} ) => { navigateUnsafe(path, options); }; खैर, अब यह एक असली राउटर है! बहुत कमज़ोर, लेकिन फिर भी काम कर रहा हूँ। हमारे पास कार्यान्वयन के लिए अभी भी कुछ हुक और घटक हैं, लेकिन यहां से यह बहुत आसान हो जाता है। चरण 2: हुक हुक के लिए, हम सरल हुक से शुरुआत कर सकते हैं जो वर्तमान स्थान और वर्तमान मार्ग लौटाते हैं। वे अपने आप में काफी आसान हैं, लेकिन उन्हें वन-लाइनर में बदल देता है। जिस तरह से हमने पहले अपनी अनिवार्य एपीआई को डिज़ाइन किया था, उससे हमें इन हुक के लिए कोड को काफी कम करने की अनुमति मिली। यूज़सिंकएक्सटर्नलस्टोर const useLocation = () => { return useSyncExternalStore(history.subscribe, history.getLocation); }; const useCurrentRoute = () => { return useSyncExternalStore(subscribe, getCurrentRoute); }; जब ऐसे घटकों को कोड किया जाता है जिन्हें केवल एक विशिष्ट मार्ग/मार्गों के सेट पर प्रस्तुत किया जाना चाहिए, तो आप वर्तमान मार्ग प्राप्त करने के लिए उपयोग कर सकते हैं, जांचें कि क्या यह मानदंडों से मेल खाता है, और फिर इसके पैरामीटर का उपयोग करें (या एक त्रुटि फेंकें)। useCurrentRoute लेकिन यह इतना सामान्य कार्य है कि हमारे उपयोगकर्ताओं को इसके लिए अपना स्वयं का हुक लिखना अपराध होगा - हमारे राउटर को इसे बॉक्स से बाहर प्रदान करना चाहिए। function useRoute (filter: RouteFilter , strict?: true): RouteWithParams ; function useRoute (filter: RouteFilter , strict: false): RouteWithParams | undefined; function useRoute (filter: RouteFilter , strict?: boolean): RouteWithParams | undefined { const currentRoute = useCurrentRoute(); const normalizedFilter = Array.isArray(filter) ? filter : isParsedRoute(filter) ? [filter] : Object.values(filter); const isMatching = !!currentRoute && normalizedFilter.some(route => currentRoute.matches(route)); if (isMatching) return currentRoute as RouteWithParams ; else { if (strict === false) return undefined; throw new RouteMismatch( `Current route doesn't match provided filter(s)` ); } } इस हुक के दो संस्करण हैं: सख्त और आरामदायक। यदि उपयोगकर्ता दूसरे पैरामीटर के रूप में पास करता है (या कुछ भी पास नहीं करता है, क्योंकि डिफ़ॉल्ट मान है) यदि वर्तमान मार्ग प्रदान किए गए फ़िल्टर में से किसी एक से मेल नहीं खाता है तो यह हुक एक त्रुटि फेंक देगा। true true इस तरह, आप निश्चिंत हो सकते हैं कि हुक एक मिलान मार्ग लौटाएगा या बिल्कुल भी नहीं लौटाएगा। यदि दूसरा पैरामीटर गलत है, तो अपवाद फेंकने के बजाय, यदि वर्तमान मार्ग फ़िल्टर से मेल नहीं खाता है, तो हुक बस अपरिभाषित वापस आ जाएगा। टाइपस्क्रिप्ट में इस व्यवहार का वर्णन करने के लिए, हम नामक सुविधा का उपयोग करते हैं। यह हमें विभिन्न प्रकारों के साथ कई फ़ंक्शन परिभाषाओं को परिभाषित करने की अनुमति देता है, और जब उपयोगकर्ता ऐसे फ़ंक्शन को कॉल करता है तो टाइपस्क्रिप्ट स्वचालित रूप से उपयोग के लिए एक को चुन लेगा। फ़ंक्शन ओवरलोडिंग पथ पैरामीटर के अलावा, कुछ डेटा खोज पैरामीटर में पारित किया जा सकता है, तो आइए उन्हें स्ट्रिंग से मैपिंग में पार्स करने के लिए एक हुक जोड़ें। इसके लिए, हम अंतर्निहित ब्राउज़र API का उपयोग करेंगे। URLSearchParams const useSearchParams = () => { const location = useLocation(); return useMemo(() => { return Object.fromEntries( (new URLSearchParams(location.search)).entries() ); }, [location.search]); }; और इस अनुभाग में अंतिम हुक है जो काफी सरल है: यह केवल कॉलबैक स्वीकार करेगा और कॉल को में एक प्रभाव में लपेट देगा, यदि अवरोधक बदलता है तो उसे फिर से संलग्न करें। useNavigationBlocker history.addBlocker const useNavigationBlocker = (cb: NavigationBlocker) => { useEffect(() => { return history.addBlocker(cb); }, [cb]); }; अब, चलो घटकों में कूदें! चरण 3: घटक राउटिंग लाइब्रेरीज़ का उल्लेख करते समय सबसे पहले कौन सा घटक दिमाग में आता है? मुझे यकीन है कि यह है या, कम से कम, कुछ इसी तरह का है। जैसा कि आपने पहले देखा, हमारे हुक एक अच्छी तरह से डिज़ाइन किए गए अनिवार्य एपीआई के कारण बहुत सरल थे जो सभी भारी सामान उठाता है। Route घटकों के लिए भी यही बात लागू होती है; इन्हें उपयोगकर्ता द्वारा कोड की कुछ पंक्तियों में आसानी से कार्यान्वित किया जा सकता है। लेकिन हम वहां एक गंभीर रूटिंग लाइब्रेरी हैं, आइए बॉक्स में बैटरी शामिल करें :) type RouteProps = { component: ComponentType, match: RouteFilter }; const Route = ({ component: Component, match }: RouteProps) => { const matchedRoute = useRoute(match, false); if (!matchedRoute) return null; return ( ); }; ख़ैर, यह आसान था! क्या आप अनुमान लगाना चाहते हैं कि हम घटक को कैसे कार्यान्वित करते हैं? :) NotFound type NotFoundProps = { component: ComponentType }; const NotFound = ({ component: Component }: NotFoundProps) => { const currentRoute = useCurrentRoute(); if (currentRoute) return null; return ( ); }; और हमारे राउटर के लिए आवश्यक अंतिम घटक है, जो थोड़ा अधिक मुश्किल है। आप केवल का उपयोग नहीं कर सकते क्योंकि यह हमेशा कठिन नेविगेशन शुरू करेगा और किसी प्रकार की सुरक्षा प्रदान नहीं करता है। तो, आइए इन मुद्दों पर ध्यान दें: Link type LinkProps = Omit , 'href'> & ( // Our link accepts either type-strict href // or relaxed unsafeHref { href: Path , unsafeHref?: undefined } | { href?: undefined, unsafeHref: string } ) & { action?: 'push' | 'replace' }; const Link = ({ action = 'push', onClick, href, unsafeHref, ...props }: LinkProps) => { const hrefToUse = (href ?? unsafeHref)!; const targetsCurrentTab = props.target !== '_blank'; const localOnClick: MouseEventHandler = (event) => { if (onClick) { onClick(event); if (event.isDefaultPrevented()) { // User-defined click handler cacnelled navigation, we should exit too return; } } const inNewTab = !targetsCurrentTab || event.ctrlKey || event.shiftKey || event.metaKey || event.button === 1; if (!isExternal && !inNewTab) { event.preventDefault(); navigateUnsafe(hrefToUse, { action }); } }; const isExternal = useMemo(() => { if (!hrefToUse) return false; return new URL(hrefToUse, window.location.href).origin !== location.origin; }, [hrefToUse]); return }; फ़ंक्शन को के लिए, घटक उस यूआरएल को टाइप करता है जिसे आप पास करते हैं लेकिन आपको एक मनमाना स्ट्रिंग यूआरएल (एस्केप हैच के रूप में या बाहरी लिंक के लिए) प्रदान करने की भी अनुमति देता है। के व्यवहार को ओवरराइड करने के लिए, हम अपना स्वयं का श्रोता संलग्न करते हैं, जिसके अंदर हमें मूल (हमारे घटक को पारित) को कॉल करने की आवश्यकता होगी। navigate Link onClick onClick Link उसके बाद, हम जाँचते हैं कि क्या नेविगेशन पहले से ही डेवलपर द्वारा निरस्त नहीं किया गया था (यदि ऐसा था, तो हमें घटना को अनदेखा करना चाहिए)। यदि सब कुछ अच्छा है, तो हम जाँचते हैं कि क्या लिंक बाहरी नहीं है और क्या इसे वर्तमान टैब में खुला रहना चाहिए। और केवल तभी हम अंतर्निहित हार्ड नेविगेशन को रद्द कर सकते हैं, और इसके बजाय, अपने स्वयं के फ़ंक्शन को कॉल कर सकते हैं। navigateUnsafe और अब, हमें केवल फ़ंक्शन से अपने सभी फ़ंक्शंस, हुक और घटकों (इतिहास से सीधे पुन: निर्यात किए गए कुछ फ़ंक्शंस के साथ) को वापस करने की आवश्यकता है। createRouter return { // Directly re-exported from history go: history.go, back: history.back, forward: history.forward, addBlocker: history.addBlocker, getLocation: history.getLocation, subscribeToLocation: history.subscribe, // Imperative API subscribe, getCurrentRoute, navigate, navigateUnsafe, // Hooks useLocation, useCurrentRoute, useRoute, useSearchParams, useNavigationBlocker, // Components Link, Route, NotFound, }; और इसके साथ ही, हमारा राउटर पूरा हो गया। अब, हम अपने अभी बनाए गए टीनी-वीनी राउटर को प्रदर्शित करने के लिए अपना टीनी-वीनी ऐप बना सकते हैं! वैसे, आप इस राउटर का पूरा कोड (एक उदाहरण ऐप के कोड सहित) पा सकते हैं। यहां पहेली के टुकड़ों को एक साथ रखना तो, यह सभी कोड एक साथ कैसे जुड़ते हैं? बहुत सफ़ाई से, अगर मैं ख़ुद ऐसा कहूँ! कल्पना कीजिए कि आप नोट लेने वाला ऐप बना रहे हैं। सबसे पहले, आप मार्गों को परिभाषित करके और इस तरह एक राउटर बनाकर शुरुआत करेंगे: export const routes = defineRoutes({ // Yep, this will be very minimal app root: '/', newNote: '/new', note: '/note/:noteId', }); const router = createRouter(routes); // Export functions and component you will be using export const { navigate, Link, Route, NotFound, useRoute, useNavigationBlocker } = router; और फिर, आप उन मार्गों को लिंक करते हैं जिन्हें आपने पृष्ठ घटकों के साथ परिभाषित किया है: function App() { return ( {/* This is how you build URL for Link */} View all notes Create new ) } में होने पर, आपको URL से एक नोट आईडी प्राप्त करने की आवश्यकता होती है, इसलिए आप एक हुक का उपयोग करते हैं: NoteDetailsPage useRoute export const NoteDetailsPage = () => { const { getNote } = useNotes(); const { params } = useRoute(routes.note); const note = getNote(params.noteId); return note ? (<> {note.title} {note.text} ) : ( Not found ); }; और एक नया नोट बनाते समय, आप शायद उपयोगकर्ता के इरादे की पुष्टि करना चाहेंगे यदि वे नोट को सहेजे बिना चले जाते हैं: export const NewNotePage = () => { const saveNote = () => { isSubmittingNoteRef.current = true; const note = createNote(title, text); // And this is programmatic redirect navigate(routes.note.build({ noteId: note.id })); isSubmittingNoteRef.current = false; }; const [title, setTitle] = useState(''); const [text, setText] = useState(''); const { createNote } = useNotes(); const isSubmittingNoteRef = useRef(false); useNavigationBlocker((isSoftNavigation) => { const dirty = title !== '' || text !== ''; if (!dirty || isSubmittingNoteRef.current) return false; if (isSoftNavigation) { const confirmation = confirm('Do you want to leave?'); return !confirmation; } else { return true; } }); return <> New note setTitle(e.target.value)} /> setText(e.target.value)} /> Save ; }; संभावित सुधार जबकि हमारा राउटर वास्तव में रूट करता है, इसका टैनस्टैक राउटर, रिएक्ट-राउटर, या नेक्स्ट.जेएस राउटर जैसे उत्पादन-तैयार समाधानों से कोई मुकाबला नहीं है। मेरा मतलब है कि यह कोड की केवल ~500 पंक्तियाँ हैं, यह बहुत अधिक नहीं है। लेकिन वास्तव में क्या कमी है? सबसे पहले, सर्वर साइड रेंडरिंग। आज, सभी ऐप्स को SSR की आवश्यकता नहीं हो सकती है, लेकिन सभी रूटिंग लाइब्रेरीज़ से इसका समर्थन करने की अपेक्षा की जाती है। एक स्ट्रिंग में सर्वर-साइड रेंडरिंग जोड़ने (एसएसआर स्ट्रीमिंग नहीं!) में एक अलग बनाना शामिल होगा जो वर्तमान स्थान को मेमोरी में संग्रहीत करेगा (क्योंकि सर्वर पर कोई इतिहास एपीआई नहीं है) और उसे फ़ंक्शन में प्लग करें। history createRouter मुझे इस बात की जानकारी नहीं है कि स्ट्रीमिंग एसएसआर को लागू करना कितना कठिन होगा, लेकिन मुझे लगता है कि यह सस्पेंस के समर्थन से मजबूती से जुड़ा होगा। दूसरा, यह राउटर समवर्ती रेंडरिंग के साथ अच्छी तरह से एकीकृत नहीं होता है। अधिकतर हमारे उपयोग के कारण, क्योंकि यह के साथ संगत नहीं है। यह फटने से बचने के लिए इस तरह से काम करता है: ऐसी स्थिति जहां यूआई का एक हिस्सा एक विशेष स्टोर वैल्यू के साथ प्रस्तुत किया गया है, लेकिन बाकी यूआई एक अलग के साथ प्रस्तुत किया गया है। useSyncExternalStore गैर-अवरुद्ध ट्रांज़िशन और इस वजह से, राउटर सस्पेंस के साथ अच्छी तरह से एकीकृत नहीं होता है, क्योंकि निलंबित होने वाले प्रत्येक स्थान अपडेट के लिए एक फ़ॉलबैक दिखाया जाएगा। वैसे, मैंने इस में रिएक्ट में समवर्तीता को कवर किया है, और , मैं सस्पेंस, डेटा फ़ेचिंग और हुक के बारे में बात करता हूं। लेख इसमें use लेकिन इन कमियों के बावजूद, मुझे आशा है कि आपको यह लेख दिलचस्प लगा होगा और आपने अपना राउटर भी बना लिया होगा :)