पोल : वैकल्पिक मापदंडों में रुचि व्यक्त करने के लिए, कृपया इस टिप्पणी के साथ "+1" पर प्रतिक्रिया दें।

नोट : वैकल्पिक पैरामीटर पहले से ही इस आरएफसी के साथ संभव हैं, उनके पास केवल एक स्पष्ट वाक्यविन्यास नहीं है (देखें कैविट्स अनुभाग)।

पोल : कैच-सभी मापदंडों में रुचि व्यक्त करने के लिए, कृपया इस टिप्पणी के साथ "+1" पर प्रतिक्रिया दें।

नोट : कृपया इस धागे में कैच-सभी मापदंडों के लिए अपने उपयोग के मामले को साझा करें! हम समस्या-स्थान को अधिक समझना पसंद करेंगे।

आरक्षित ३

Ricardo.ch पर, हम प्रत्येक मार्ग के लिए एक स्थानीय उपसर्ग का उपयोग करते हैं जो रूटिंग को थोड़ा अधिक जटिल बनाते हैं।

मान्य मार्गों का उदाहरण:

• / - ऑटो-डिटेक्टेड लोकेल के साथ होमपेज
• /:locale - मजबूर लोकेल के साथ होमपेज
• /:locale/search - खोज पृष्ठ
• /:locale/article/:id - लेख पृष्ठ

क्या आपको लगता है कि ऐसे उपसर्ग मापदंडों का समर्थन किया जा सकता है?

फिलहाल, हम https://www.npmjs.com/package/next-routes का उपयोग करते हैं

एक और बात: लेख पृष्ठ के लिए, हम भी आईडी से पहले एक स्लग का समर्थन करते हैं जैसे /de/article/example-article-123 जहां आईडी 123 होगी। यह next-routes का उपयोग करते हुए काफी जटिल रीजेक्स के माध्यम से किया जाता है और मैं नहीं देखें कि यह फ़ाइल-सिस्टम API के साथ कैसे व्यक्त किया जा सकता है।

@ValentinH प्रदान किए गए मार्ग फाइलसिस्टम एपीआई का उपयोग करके सभी संभव हैं - आपके द्वारा दिए गए मार्ग:

• / => pages/index.js
• /:locale => pages/$locale/index.js
• /:locale/search => pages/$locale/search.js
• /:locale/article/:id => pages/$locale/article/$id.js

हम आईडी / डी / लेख / उदाहरण-लेख -123 की तरह आईडी से पहले एक स्लग का समर्थन करते हैं जहां आईडी 123 होगी

यह उपयोग मामला ऊपर संबोधित किया गया है:

मार्ग के नाम के बीच में नामांकित पैरामीटर दिखाई नहीं दे सकते हैं।

इसका मतलब है कि blog-$id.js नाम वाले पृष्ठ का शाब्दिक अर्थ होगा और /blog-1 मेल नहीं खाता। आप या तो अपने पृष्ठों का पुनर्गठन /blog/$id.js कर सकते हैं या पूरे URL सेगमेंट को एक नामित पैरामीटर में बदल सकते हैं और अपने एप्लिकेशन के कोड में blog- कर सकते हैं।

क्या यह समाधान आपकी आवश्यकताओं को पूरा नहीं करता है? हम आपकी विशिष्ट आवश्यकताओं के बारे में अधिक जानना पसंद करेंगे।

उत्तर के लिए बहुत बहुत धन्यवाद।

मैं एक फ़ोल्डर और एक फ़ाइल के रूप में $locale/index.js का उपयोग करने के बारे में नहीं सोचा था, यह वास्तव में साफ है!

"बीच में नामित पैरामीटर" के बारे में, मैंने इसे अनदेखा कर दिया क्योंकि मुझे लगा कि स्लग के गतिशील होने का मतलब अलग था। हालांकि, आप पूरी तरह से सही हैं और यह आपके द्वारा उल्लिखित पैराग्राफ द्वारा संबोधित किया गया है। एप्लिकेशन कोड में स्लग को स्ट्रीप करना 🙂 जाने का रास्ता होगा

क्या ऐसा कुछ होगा (। Paridden से। Pariles .files / .folders) संभव होगा?

pages/
├── .root.js
├── blog/
│ ├── .id/
│ │ ├── index.js
│ │ └── comments.js <-- optional?
├── customers/
│ ├── .customer/
│ │ ├── .post/
│ │ │ └── index.js
│ │ ├── index.js
│ │ └── profile.js
│ ├── index.js
│ └── new.js
├── index.js
└── terms.js

या $ को छोड़ दें ताकि कोई अपनी फ़ाइलें पा सके: D लेकिन हमेशा एक परम को इंगित करने के लिए $ फ़ोल्डर का उपयोग करें?

pages/
├── $root.js
├── blog/
│ ├── $id/
│ │ ├── index.js
│ │ └── comments.js <-- optional?
├── customers/
│ ├── $customer/
│ │ ├── $post/
│ │ │ └── index.js
│ │ ├── index.js
│ │ └── profile.js
│ ├── index.js
│ └── new.js
├── index.js
└── terms.js

मैं एक npm संकुल के साथ काम करने वाले ऐप में वैकल्पिक मापदंडों के लिए इस उपयोग-मामले का उपयोग करता था। इनमें वैकल्पिक रूप से गुंजाइश हो सकती है। ऐसे मार्ग हैं:

• /packages/express
• /packages/express/dependencies
• /packages/@babel/core
• /packages/@babel/core/dependencies

इसलिए मूल रूप से, स्कोप पैरामीटर वैकल्पिक है, लेकिन यह केवल एक स्कोप है जब यह @ शुरू होता है।
तो /packages/express/dependencies और /packages/@babel/core खंडों की समान राशि है, लेकिन एक मामले में यह /dependencies express और दूसरे में यह /index @babel/core ।

अंत में इसे निम्नलिखित मार्गों से react-router में हल किया गया:

<Switch>
  <Route path={`/packages/`} exact component={PackagesOverview} />
  <Route path={`/packages/:name(@[^/]+/[^/]+)`} component={PackageView} />
  <Route path={`/packages/:name`} component={PackageView} />
</Switch>

मुझे यकीन नहीं है कि मुझे इस RFC में उपयोग-मामले के लिए एक समाधान दिखाई दे रहा है।

कैच-ऑल यूज़ के मामलों के लिए, मैं किसी भी नेस्टेडली नेस्टेड डेटा में किसी भी गहरी लिंकिंग के बारे में सोच रहा हूं, जैसे कि फोल्डर स्ट्रक्चर्स, ट्रीव्यूज, टेंपरैप्स।

मेरे 2 सेंट: फ़ाइल नाम में डॉलर के संकेत एक बुरा विचार है क्योंकि वे एक सतर्क के रूप में गोले द्वारा उपयोग किए जाते हैं। आप rm $root.js चलाने की कोशिश कर रहे लोगों को भ्रमित करने जा रहे हैं। अंडरस्कोर एक सभ्य विकल्प की तरह लगता है।

अधिक मोटे तौर पर: कई लोगों की तरह, मैंने अतीत में इसके समाधान के रूप में फाइल सिस्टम का लाभ उठाने की कोशिश की है। अंत में, मुझे लगता है कि फाइल सिस्टम कभी भी उस संपूर्ण अभिव्यंजना को प्रस्तुत करने वाला नहीं है जिसे आप खोज रहे हैं। उदाहरण के लिए, घोषणात्मक राउटर आमतौर पर आपको एक गतिशील पैरामीटर के लिए एक सत्यापन पैटर्न निर्दिष्ट करते हैं। उस स्थिति में, स्कीमा का एक हिस्सा फाइल सिस्टम पर रहता है, और दूसरा भाग कोड में। चिंताओं का अलग होना एक अच्छी बात है, लेकिन इस मामले में, यह किसी भी चीज़ से अधिक एक तकनीकी सीमा है।

@ValentinH की तरह हम $ लोकेल

क्या हमें /page.ts और /page/$locale/page.ts का उपयोग करना चाहिए?

क्योंकि हम "डिफ़ॉल्ट" लोकेल या पूर्वनिर्धारित लोकेल (उपयोगकर्ता सेटिंग्स) का उपयोग कर सकते हैं, उन मामलों में हम $ लोकेल परम का उपयोग नहीं करते हैं।

लेकिन हमारे पास अधिक उपयोग के मामले हैं: / कार / खोज / $ वैकल्पिक-फ़िल्टर -1 / $ वैकल्पिक-फ़िल्टर -2 / $ वैकल्पिक-फ़िल्टर -3

जहां वैकल्पिक-फ़िल्टर -1: रंग-लाल, वैकल्पिक-फ़िल्टर -2: ब्रांड-फ़ोरड, आदि ...

और वैकल्पिक params के लिए, जैसे कुछ / $ आवश्यक-परम / और / $ $ वैकल्पिक-परम /?

बहुत बढ़िया कि यह रोडमैप पर आ रहा है!

मुझे हालांकि @timdp को सपोर्ट करने में झंकार करनी होगी। जब आप touch $file भी नहीं touch \$file; vim $file एक फ़ाइल के बिना खुल जाएगा (क्योंकि $ फ़ाइल एक परिभाषित चर नहीं है)।
इसी तरह एक शेल में पूरा होने वाला टैब सभी चर को सूचीबद्ध करेगा, एक बार फिर भ्रम की स्थिति लाएगा।

मैं दो विकल्पों का प्रस्ताव कर रहा हूं जो मुझे लगता है कि सही संघ देता है और गोले में काम करना चाहिए:

• = इसे page is a customer =customer रूप में पढ़ा जा सकता है। तुम भी इसे मानसिक रूप से एक बृहदान्त्र के रूप में फैला सकते हो, बस इस प्रकार नामित मापदंडों के लिए सबसे सामान्य रूप जैसा दिखता है।
• @ रूप में यह भी कुछ हद तक अच्छी तरह से पढ़ता है। a customer @customer

एक अन्य विकल्प घुंघराले ब्रेसिज़ का उपयोग करना होगा (जब तक कि वे कुछ फ़ाइल सिस्टम पर आरक्षित वर्ण नहीं हैं)। यह पैरामीटर सिंटैक्स "पूर्व कला" भी है और कई अन्य राउटर्स द्वारा उपयोग किया जाता है:

pages/
├── {root}.js
├── blog/
│ └── {id}.js
├── customers/
│ ├── {customer}/
│ │ ├── {post}.js
│ │ ├── index.js
│ │ └── profile.js
│ ├── index.js
│ └── new.js
├── index.js
└── terms.js

यह मार्ग खंड और प्रति खंड में कई मापदंडों के बीच में पैरामीटर रखने की अनुमति देगा क्योंकि यह स्पष्ट है कि पैरामीटर कहां से शुरू होता है और कहां समाप्त होता है, जैसे /product-{productId}-{productColor} ।

इतना उत्साहित कि गतिशील मार्ग Next.js पर आ रहे हैं!

नामित मापदंडों के लिए वाक्यविन्यास के बारे में, यह कुछ ऐसा है जो स्पेक्ट्रम पर चर्चा की गई है: https://spectrum.chat/next-js/general/rfc-move-parameterized-rout-to-the-file-system~ce289c5e-ff66 -4a5b-8e49-08548adfa9c7। यह यहाँ चर्चा के लिए इनपुट के रूप में उपयोग करने लायक हो सकता है। निजी तौर पर, मुझे पसंद है कि कैसे Sapper [brackets] का उपयोग कर रहा है। यह भी कुछ ऐसा है जो Nuxt संस्करण 3 में लागू होने जा रहा है। विभिन्न फ्रेमवर्क गतिशील फाइलसिस्टम-आधारित मार्गों के लिए एक ही प्रारूप का उपयोग करते हैं जो एक अच्छी बात लगती है।

<Link /> के उपयोग के बारे में, मुझे लगता है कि डेवलपर्स आसानी से दोनों href और as विशेषताओं को सेट करना भूल जाएंगे। मुझे लगता है कि इसे href विशेषता में "मर्ज" करना संभव नहीं है क्योंकि यह एक टूटने वाला बदलाव पेश करेगा, लेकिन मुझे लगता है कि इसे और अधिक सुरुचिपूर्ण तरीके से हल किया जा सकता है।

घुंघराले ब्रेस दुर्भाग्य से समूह आदेशों के लिए बश द्वारा उपयोग किए जाते हैं।

मैं <Link /> के उपयोग के संबंध में @ stephan281094 से सहमत हूं, यह गलतियों का स्रोत होगा।

डायनामिक रूटिंग एक अत्यंत उपयोगी सुविधा है, इसलिए यह वास्तव में बहुत बढ़िया है कि आप लोग इस पर ध्यान दें और एक समाधान, विशाल सहारा लेकर आए!

जबकि इस विषय पर, वाइल्डकार्ड मार्गों को भी प्रस्ताव के लिए एक योग्य जोड़ा जाएगा। आपने भविष्य में जांच करने के लिए कुछ के रूप में कैच-सभी मापदंडों का उल्लेख किया है, लेकिन यह उन मामलों को कवर नहीं करता है जहां आप /category/* जैसा कुछ करना चाहते हैं, जिसमें एन स्तर का स्तर हो सकता है, और आप सभी चाहते हैं उन्हें category पृष्ठ प्रदान करने के लिए।

क्या : सुरक्षित रूप से उपयोग करना संभव है? यदि ऐसा है, तो यह मेरा वोट होगा, क्योंकि हर कोई एक्सप्रेस से उस सम्मेलन से पहले ही परिचित है।

शेल चर के साथ $ परस्पर विरोधी होने के कारण, मैं व्यक्तिगत रूप से इसका विरोध करता हूं।

क्या : सुरक्षित रूप से उपयोग करना संभव है? यदि ऐसा है, तो यह मेरा वोट होगा, क्योंकि हर कोई एक्सप्रेस से उस सम्मेलन से पहले ही परिचित है।

जाहिरा तौर पर : विंडोज में एक निषिद्ध चरित्र है, इसलिए यह संभवतः सुरक्षित नहीं है। _ जाना या तो आदर्श नहीं है, क्योंकि URL में अंडरस्कोर का उपयोग किया जा सकता है। मुझे लगता है कि [brackets] एक अच्छा समाधान है, क्योंकि यह अधिक भविष्य का प्रमाण है। अगर Next.js भविष्य में post-12345 जैसे मार्गों का समर्थन करना चाहता है, तो इस सिंटैक्स का उपयोग करके इसे एक ब्रेकिंग परिवर्तन की शुरुआत किए बिना किया जा सकता है।

तो बचने के लिए पात्रों की एक सूची होगी:

• फ़ाइल सिस्टम के साथ विरोध: : , * , " , < , > , |
• शेल चर के साथ संघर्ष: $
• बैश ब्रेस विस्तार { , } साथ संघर्ष

और कुछ?

यह कारणों की एक जोड़ी के लिए एक केंद्रीकृत मार्ग फ़ाइल होने की हमारी आवश्यकता को समाप्त नहीं करेगा:

• हमारे पास स्वतः उत्पन्न होने वाला साइटमैप है, और इसे परिभाषित करने के लिए अकेले फाइलसिस्टम पर्याप्त नहीं है।
• हमने मार्गों के नाम और गंतव्य का उपयोग किया "पृष्ठ" डेटा द्वारा निर्धारित किए जाते हैं, बजाय कुछ के जो निर्माण के समय में पता करने योग्य है। यह पता लगाने के लिए कि क्या नाम और परमस के आधार पर लोड करने के लिए पृष्ठ मार्ग विन्यास द्वारा संचालित है।

हम इन कारणों से अपने पृष्ठों का फ़ोल्डर भी बनाते हैं:

• हम रिले का उपयोग करते हैं, और इसका मतलब है कि ग्राफकॉल से जुड़े मॉड्यूल को विशिष्ट रूप से नामित करने की आवश्यकता है। उस कारण से हम अक्सर रूट सेगमेंट के नाम मॉड्यूल नामों के समान नहीं हो सकते। index.js निश्चित रूप से अद्वितीय नहीं है, और मुझे ऐसे स्थान दिखाई देते हैं जहां हमारे पास edit जैसे कई सामान्य खंड होंगे।
• हम पृष्ठ-मॉड्यूल के भाई-बहनों के रूप में एक-पृष्ठ-विशिष्ट घटकों का सह-पता लगाना पसंद करते हैं, जो Next.js पृष्ठों फ़ोल्डर के भीतर अनुमति नहीं देता है।

अनिवार्य रूप से हमारा पैटर्न हमारे पृष्ठों के फ़ोल्डर को बनाने के लिए हमारे केंद्रीकृत मार्ग विन्यास का उपयोग करना है, जिसमें ऐसी फाइलें हैं जो कोडबेस में कहीं और से आयात / निर्यात मॉड्यूल से ज्यादा कुछ नहीं हैं।

उस अंत तक, मेरा ध्यान इस बात पर अधिक है कि क्या यह प्रस्ताव हमारी मौजूदा पृष्ठ पीढ़ी प्रक्रिया के लिए एक उन्नत आउटपुट प्रारूप के रूप में काम कर सकता है, ताकि हमें कम से कम कस्टम सर्वर की आवश्यकता न होने का लाभ मिल सके।

मैं अपने उपयोग के कुछ मामलों में कहीं और गया हूं: https://gist.github.com/AndrewIngram/8d4c4ccd9bd10415a375caacade9f5ca

मुख्य बात जो मैं नहीं देख रहा हूं, वह अंतर्निहित मापदंडों का समर्थन कर रहा है जो कि उदाहरण के लिए, फ़ाइल-सिस्टम में व्यक्त नहीं किए गए हैं।

मान लीजिए कि हमारे पास इस तरह का एक URL है:

/some-vanity-url/

जहाँ वर्तमान में Next.js की शर्तें हैं, हम यह चाहते हैं कि यह किसी ऐसे उत्पाद पृष्ठ पर जाए, जिसमें कई क्वेरी पैरामीटर हों, जैसे Product.js?id=foo&language=en ।

इसी तरह, हमारी वेबसाइट पर अधिकांश देशों की "साइटें" एक शीर्ष-स्तरीय खंड द्वारा स्कोप की जाती हैं, जैसे es या ie , लेकिन gb साइट उस सेगमेंट के बिना माउंट की जाती है। इसका मतलब है कि सभी gb पृष्ठों में एक निहित country पैरामीटर है, जबकि अन्य सभी देशों के लिए यह स्पष्ट है।

अन्य नकारात्मक पहलू यह है कि क्योंकि हमारे मामले में, एक ही 'पेज' URL आर्किटेक्चर में कई आरोह बिंदुओं पर मौजूद हो सकता है, हम वास्तव में हमारी तुलना में बंडलों (यानी कई डुप्लिकेट एंट्री पॉइंट) की एक बड़ी संख्या के साथ समाप्त होने जा रहे हैं। व्यवहार में जरूरत है।

पूरे प्रस्ताव पर ऐसा लगता है कि यह सबसे आम उपयोग के मामलों के लिए अच्छी तरह से काम करने वाला है, लेकिन यह _all_ मामलों में मार्ग कॉन्फ़िगरेशन या कस्टम सर्वर की आवश्यकता को कम नहीं करता है। लेकिन यह मानते हुए कि आज मैं जिस तरह से रूपरेखा का उपयोग करने की अपनी क्षमता को प्रतिस्थापित नहीं करता हूं, मुझे पसंदीदा हैप्पी-पाथ एपीआई होने के कारण कोई वास्तविक आपत्ति नहीं है।

मैं {id} सुझाव का समर्थन करता हूं। यह कई पारमों की अनुमति देता है और मुझे लगता है कि यह बहुत बेहतर है। यह रिएक्ट के साथ भी बेहतर बैठता है।

मैं file/&param.js चरित्र के पक्ष में हूं। सीधे यूआरएल से लिया गया है और यह फाइल सिस्टम या बैश के साथ टकराव की तरह नहीं दिखता है।

मैं _ और शायद next.config.js में ओवरराइड के लिए अनुमति देता हूँ, जिन्हें वास्तव में कुछ अलग चाहिए।

इस पर काम की सराहना करें। कुछ समय के लिए इसे चाहने लगा! ❤️

गजब का! 🎉🎉🎉

यहाँ मेरा एकमात्र मुद्दा यह है कि Link दोनों को href और as परम की आवश्यकता है।

मेरा मानना ​​है कि हम सिर्फ <Link to="blog/123" /> लिख सकते हैं: क्योंकि नेक्स्टज पहले से ही पन्नों के फोल्डर में फाइलों के आधार पर सभी मार्गों को जानता है, "/blog/$id" यह आसानी से

तो बचने के लिए पात्रों की एक सूची होगी:

& बैश में एक नियंत्रण ऑपरेटर है जो एक async उपधारा में तर्क के बाईं ओर चलता है। प्लेनटेक्स्ट: open pages/&customer बैकग्राउंड शेल में open pages/ बैकग्राउंड में कमांड customer चलेंगे।

यह वास्तव में अच्छा लग रहा है।

ऐसा लगता है कि यह एकल फ़ाइल निर्देशिकाओं (जैसे मूल उदाहरण में /blog/$id ) बनाएगा। यदि आप दो अनुगामी मार्ग पैरामीटर (यानी /git/compare/$hash1/$hash2 ) चाहते हैं तो यह और भी अधिक बोझिल हो जाता है।

मुझे यह भी पसंद नहीं है कि ब्लॉग पोस्ट के लिए फ़ाइल नाम $id.js । इसका नाम blog.js होने से यह बहुत अधिक वर्णनात्मक होगा।

शायद एक @customRoute डेकोरेटर के साथ गठबंधन?

// pages/blog.js
import {useRouter, @customRoute} from 'next/router'

@customRoute('/blog/:id')
function BlogPost() {
  const router = useRouter()
  // `blogId` will be `'how-to-use-dynamic-routes'` when rendering
  // `/blog/how-to-use-dynamic-routes`
  const blogId = router.query.id
  return <main>This is blog post {blogId}.</main>
}

export default BlogPost

यह प्रस्तावित कैच-सभी मापदंडों के लिए एक क्लीनर समाधान प्रदान करता है।

डेकोरेटर को फ़ंक्शंस पर लागू नहीं किया जा सकता है (शायद यह तब से बदल गया है जब मैंने इसे आखिरी बार पढ़ा था?) और प्रस्ताव शायद वैसे भी एक लंबा रास्ता है

ठीक है, मान लीजिए कि आप उस सड़क पर जाते हैं, तो आप शायद इसे उसी तरह से करेंगे जैसे एएमपी अब कॉन्फ़िगर किया गया है:

// /pages/blog.js
export const config = {
  amp: true,
  dynamicRoute: true // adds a [blog] property to the query object
  // dynamicRoute: /\d+/ // could even support regex if you want
};

हालाँकि, मुझे लगता है कि इस तरह से सामान बाद में जोड़ा जा सकता है अगर यह किसी बिंदु पर उपयोगी लगता है। मुझे लगता है कि मैं आरएफसी में वर्णित के रूप में शुरू करने के लिए एक मूल समर्थन देखना चाहता हूं। उस के साथ कुछ वास्तविक उपयोग करें, फिर उसे परिष्कृत करें जहां यह टूट जाता है। मुझे यह भी लगता है कि फाइल सिस्टम वालों से बचने के लिए केवल उन पात्रों को ध्यान में रखा जाना चाहिए। इस सुविधा के निर्माण के लिए वे वास्तविक अवरोधक हैं।

कृपया, एक ऐसे चरित्र का उपयोग करना सुनिश्चित करें जो सर्वर रहित समाधानों के अनुकूल हो! (ऑन्स में, कुछ ऐसे किरदार हैं जो परेशानी पैदा कर सकते हैं)

एक घटक कुंजी के साथ एक कॉन्फ़िगर वस्तु निर्यात करना कुछ ऐसी चीज है जिससे मुझे नफरत नहीं है।

तुम भी सिर्फ एक HOC का उपयोग कर सकते हैं

function BlogPost(props) {
    return <div />
}

export default withCustomRoute(BlogPost, "/blog/:id")

क्या होगा अगर हम पेज पर कुछ स्थिर फ़ील्ड जोड़ते हैं (जैसे getInitialProps)?

// pages/blog.js
import {useRouter} from 'next/router'

function BlogPost() {
  const router = useRouter()
  // `blogId` will be `'how-to-use-dynamic-routes'` when rendering
  // `/blog/how-to-use-dynamic-routes`
  const blogId = router.query.id
  return <main>This is blog post {blogId}.</main>
}

// By default it would be as it is now
BlogPost.route = '/blog/:id';

export default BlogPost

@ dmytro-lymarenko जब आप ब्राउज़र में /blog नेविगेट करते हैं तो क्या होता है? एक 404?

क्योंकि यह संकलन समय पर निर्धारित किया जाना चाहिए, मुझे लगता है कि आपको कुछ ऐसा चाहिए होगा जो सांख्यिकीय रूप से विश्लेषण योग्य हो। एक HOC या एक स्थिर संपत्ति नहीं होगी।

आपको कुछ ऐसा चाहिए होगा जो सांख्यिकीय रूप से विश्लेषण योग्य हो। एक HOC या एक स्थिर संपत्ति नहीं होगी

अब तक दिए गए प्रत्येक स्थिर संपत्ति उदाहरण को सांख्यिकीय रूप से विश्लेषण किया जाएगा (हालांकि आप निश्चित रूप से चीजों को आसानी से तोड़ सकते हैं)। हम सिर्फ यह आग्रह कर सकते हैं कि आप अपने कार्य का निर्यात करें और उस पर मार्ग संपत्ति को एक सांख्यिकीय रूप से विश्लेषण करने योग्य तरीके से निर्धारित करें। रनटाइम रूट संपत्तियों की जाँच कर सकता है जो रनटाइम पर सेट होते हैं लेकिन हमारे स्थैतिक विश्लेषक द्वारा पकड़े नहीं गए थे और चेतावनी जारी करते हैं / एक त्रुटि फेंकते हैं।

जब आप ब्राउज़र में / ब्लॉग पर नेविगेट करते हैं तो क्या होता है? एक 404?

@kingdaro - IMO, हाँ। यदि आप दोनों /blog , और /blog/:blogId रास्तों का उपयोग करना चाहते हैं, तो आप एक निर्देशिका का उपयोग करते हैं। आप उस पथ को ओवरलोड कर रहे हैं, इसलिए निर्देशिका संरचना उचित है।

pages/
├── blog/
│ ├── $id.js
│ └── index.js

अब तक उल्लिखित सभी चरित्र विकल्पों की त्वरित समीक्षा:

प्रकटन के क्रम में

चार | कमियां
--- ---
$ | फ़ाइलनाम में डॉलर के संकेत एक बुरा विचार है क्योंकि वे एक सतर्क के रूप में गोले द्वारा उपयोग किए जाते हैं
_ | आमतौर पर एक आंतरिक मार्ग का संकेत
= |
@ | पावरशेल में स्पैट ऑपरेटर
{...} | Bash द्वारा ग्रुप कमांड्स के लिए उपयोग किया जाता है
[...] | zsh में फ़ाइल नाम पीढ़ी
: | वैध फ़ाइल नाम नहीं
& | bash में एक नियंत्रण ऑपरेटर है जो एक async उपधारा में तर्क के बाईं ओर चलता है

ठीक है, मान लीजिए कि आप उस सड़क पर जाते हैं, तो आप शायद इसे उसी तरह से करेंगे जैसे एएमपी अब कॉन्फ़िगर किया गया है:

// /pages/blog.js
export const config = {
  amp: true,
  dynamicRoute: true // adds a [blog] property to the query object
  // dynamicRoute: /\d+/ // could even support regex if you want
};

हालाँकि, मुझे लगता है कि इस तरह से सामान बाद में जोड़ा जा सकता है अगर यह किसी बिंदु पर उपयोगी लगता है। मुझे लगता है कि मैं आरएफसी में वर्णित के रूप में शुरू करने के लिए एक मूल समर्थन देखना चाहता हूं। उस के साथ कुछ वास्तविक उपयोग करें, फिर उसे परिष्कृत करें जहां यह टूट जाता है। मुझे यह भी लगता है कि फाइल सिस्टम वालों से बचने के लिए केवल उन पात्रों को ध्यान में रखा जाना चाहिए। इस सुविधा के निर्माण के लिए वे वास्तविक अवरोधक हैं।

मुझे लगता है कि कॉन्फ़िगर का उपयोग करना एक बुरा विचार है क्योंकि आपको कई फाइलों से गुजरने की जरूरत है, यह देखने के लिए कि वास्तव में क्या गतिशील है। यदि आप इसे फ़ाइल सिस्टम में सेट करते हैं तो आप इसे पहली नज़र से देख सकते हैं।

मुझे आश्चर्य है कि अगर एक से अधिक मानक मार्ग समाधान पर विचार करने के लिए कुछ होना चाहिए।

सिंपल फाइल-बेस्ड रूटिंग उन न्यू / नेक्स्ट / रिएक्ट के लिए एक बढ़िया सेलिंग पॉइंट है, या कोई भी व्यक्ति जो जल्दी से एक साधारण ऐप अप और रनिंग करना चाहता है, लेकिन यह सीमित हो सकता है। और यह मुझे लगता है कि इस पैटर्न में डायनेमिक रूटिंग को करने की कोशिश उस सादगी को बर्बाद कर सकती है और सब कुछ फ़ाइल-आधारित रखने के नाम पर अनावश्यक जटिलता को जन्म दे सकती है।

इस चर्चा को पढ़ने और Next.js के अपने स्वयं के उपयोग के बारे में सोचने के बाद, मुझे लगता है कि वैकल्पिक (पूरक) रूटिंग सिस्टम के लिए प्रथम श्रेणी का समर्थन इसे हल करने का सबसे अच्छा तरीका हो सकता है।

मुझे इस थ्रेड में कुछ आउट-ऑफ-द-बॉक्स सोच पसंद है (जैसे सज्जाकार का उपयोग करने का प्रस्ताव) लेकिन उन विचारों की निश्चित रूप से अपनी समस्याएं हैं। मुझे उम्मीद है कि हम कुछ महान up के साथ आ सकते हैं

एक घटक कुंजी के साथ एक कॉन्फ़िगर वस्तु निर्यात करना कुछ ऐसी चीज है जिससे मुझे नफरत नहीं है।

तुम भी सिर्फ एक HOC का उपयोग कर सकते हैं

function BlogPost(props) {
    return <div />
}

export default withCustomRoute(BlogPost, "/blog/:id")

यह बहुत अच्छा है, लेकिन मुझे आश्चर्य है कि अगर रूट की जानकारी कई फाइलों की तरह विभाजित हो जाती है
यह प्रबंधन करना कठिन हो सकता है।

एक स्थानीय कॉन्फ़िगरेशन (फ़ाइल में) बनाम एक वैश्विक एक ( route.js ) का प्रस्ताव देने के साथ मेरी मूल सोच, मेरी पहली टिप्पणी में वर्णित विशिष्ट परिदृश्यों को संबोधित करना था (गहरी नेस्टेड फाइलें जो उनकी निर्देशिका में एकमात्र फ़ाइल हैं, गैर-शब्दार्थ फ़ाइल नाम, और कैच-ऑल-परमेस)।

यदि उन संदर्भों में कड़ाई से उपयोग किया जाता है, तो यह बहुत कम भ्रामक है, क्योंकि URL सीधे फाइल सिस्टम पर मैप करता है, और केवल "अतिरिक्त" पैरामेट्स को स्थानीय कॉन्फ़िगरेशन द्वारा संबोधित किया जाता है।

उस ने कहा, मुझे यकीन नहीं है कि मैं उपयोगकर्ताओं को ऐसा करने से रोकने की कोशिश करूंगा, लेकिन वे चाहते हैं। हम कंसोल के लिए परिकलित रूटिंग तालिका को सुंदर रूप से प्रिंट कर सकते हैं, या इसे कुछ पूर्व निर्धारित फ़ाइल में भी सहेज सकते हैं। समस्या निवारण मार्गों की सहायता के लिए यह पर्याप्त होना चाहिए

@merelinguist का मानना ​​है कि विंडोज में = का प्रतिबंध नहीं है क्योंकि आपने सारांश तालिका में लिखा है। आप वापस लिंक कर रहे हैं कि कैसे : निषिद्ध है, लेकिन Microsoft Windows फ़ाइल के अनुसार

मैं पहले से ही एक परियोजना में गतिशील मार्गों के साथ पोर्ट कर रहा हूं जिसका मैं उत्पादन में उपयोग करता हूं (उम्मीद है कि मैं इसे इस सप्ताह लाइव कर सकता हूं)।

विशिष्ट प्रश्न हालांकि, क्या नया अगला @ कैनरी एपीआई फीचर _also_ डायनामिक रूटिंग का समर्थन करेगा?

{ path: '/api/:customer', page: '/api/$customer/index.js' }

मैंने अभी इसे अगले@8.1.1-canary.54 के साथ

@remy यह अभी तक लागू नहीं हुआ है इसे जल्द ही करने के लिए मेरी सूची में है

हमें न केवल विंडोज और लिनक्स सिस्टम, बल्कि अन्य को भी ध्यान में रखना चाहिए:
https://en.wikipedia.org/wiki/Filename#Comparison_of_filename_limitations

मैं अपने प्रस्ताव के बारे में और जानकारी जोड़ना चाहूंगा:

क्या होगा अगर हम पेज पर कुछ स्थिर फ़ील्ड जोड़ते हैं (जैसे getInitialProps)?

// pages/blog.js
import {useRouter} from 'next/router'

function BlogPost() {
  const router = useRouter()
  // `blogId` will be `'how-to-use-dynamic-routes'` when rendering
  // `/blog/how-to-use-dynamic-routes`
  const blogId = router.query.id
  return <main>This is blog post {blogId}.</main>
}

// By default it would be as it is now
BlogPost.route = '/blog/:id';

export default BlogPost

1. डेवलपर उस मार्ग संपत्ति के लिए रनटाइम चर का उपयोग नहीं कर सकता है

const route = `/blog/${somethingElse}`;
BlogPost.route = route; // is not allowed

1. जब हम इस वर्तमान RFC के साथ पृष्ठ प्रकट करते हैं (जहाँ फ़ोल्डर में यह पहचानने के लिए कुछ वर्ण होता है कि यह गतिशील है) तो मुझे यह अंतर दिखाई नहीं देता है कि क्या हम फ़ाइल को पढ़ने के साथ इस पृष्ठ के प्रकट होने का निर्माण करते हैं और पृष्ठ पर स्थैतिक मार्ग गुण पाते हैं। उसी तरह से लिंगुई काम करता है: वे ट्रांस के लिए गतिशील होने की अनुमति नहीं देते हैं

<Trans id="msg.docs" /* id can only be static string */>
   Read the <a href="https://lingui.js.org">documentation</a>
   for more info.
 </Trans>

पहले से सूचीबद्ध उपसर्गों की सूची से जा रहे हैं - मुझे आश्चर्य है कि अगर @ प्रतीक उपसर्ग का उपयोग करने का कोई मजबूत कारण _not_ है?

मुझे संदेह है कि क्या यह मूल्य है, लेकिन आपको नुक्स के साथ समानता मिलती है - जिसका अर्थ है कि कोई एक या दूसरे से स्विच करने पर तुरंत पता चल जाएगा कि यह कैसे काम करता है।

वैकल्पिक रूप से, क्या किसी ने उपसर्ग को एक उपयोगकर्ता विकल्प बनाने के बारे में सोचा है? लोगों को एक परियोजना को दूसरे से समझना मुश्किल हो जाता है, लेकिन इसका मतलब है कि अगर मैं चाहता था, तो मैं उपसर्ग query__{...} या कुछ और कर सकता था।

सिर्फ एक विचार।

@Remy के सुझाव के बाद, क्यों नहीं पूरी तरह से फ़ाइल सिस्टम से अगले पार्स मार्गों के लिए एपीआई को खोलें। उपयोगकर्ताओं को अधिक (या कम) लचीलेपन की आवश्यकता के रूप में देते हैं, और विश्वसनीय तृतीय-पक्ष रूटिंग समाधानों को प्रेरित करते हैं।

@ scf4 मेरे पास एक पुस्तकालय था जो एक PoC है, जो कि now.json मार्गों का उपयोग करता है, यहाँ नेक्स्ट के साथ यूनिवर्सल रूटिंग करने के लिए भी

मुझे उम्मीद है कि Zeit टीम क्लाइंट साइड लाइब्रेरी पर भी मार्ग पार्सर का स्रोत खोलेगी।

Nuxt को देखते हुए मुझे लगता है कि _id.js बहुत बुरा नहीं है। हाँ, हम पहले से ही _app और _document.js जैसा कि आपने उल्लेख किया है और यह सार्वजनिक रूप से नियमित नहीं है। लेकिन एक गतिशील मार्ग को भी देखा नहीं जा सकता है क्योंकि यह कई पृष्ठों के लिए एक टेम्पलेट है

यह स्थैतिक साइट निर्यात के लिए कैसे संभाला जाएगा?

(यह कभी बुरा मत मानना)

मुझे भी लगता है कि यह उपयोगी होगा यदि Next.js जनरेट किए गए रूट को एक फ़ाइल में प्रिंट करने के लिए थे (शायद डिफ़ॉल्ट रूप से छिपा हुआ)। बहुत कम से कम यह एक परियोजना पर काम कर रहे लोगों के लिए एक उपयोगी संदर्भ के रूप में काम करेगा, लेकिन यह बाद में कुछ शक्तिशाली गतिशील मार्गों के लिए भी दरवाजा खोल सकता है।

यानी, यदि यह रनटाइम पर रूट हैंडलिंग के लिए उस फाइल का उपयोग करता है, तो उपयोगकर्ताओं के लिए फाइलसिस्टम-आधारित API के लाभों को खोए बिना मार्गों (जैसे, जटिल पैटर्न मिलान के लिए) को जोड़ना / बदलना बहुत आसान होगा।

यह उन मार्गों के बारे में कुछ चुनौतियां पैदा करेगा कि कैसे उन मार्गों पर नज़र रखी जाए जिन्हें मैन्युअल रूप से बदल दिया गया है, लेकिन अगर हल किया जाए तो मुझे लगता है कि यह अब तक का सबसे अच्छा समाधान होगा।

@ scf4 Next.js में पहले से ही कस्टम सर्वर विकल्प का उपयोग करके जटिल मार्गों को करने की क्षमता है। आप जो प्रस्ताव कर रहे हैं वह पहले से उपलब्ध टूलिंग के साथ लगभग समान मात्रा में प्राप्त किया गया है।

आह हाँ, काफी साफ है।

मुझे लगता है कि एक रूट रूट फाइल जो संपादित की जा सकती है, वैसे भी बहुत बेहतर विकल्प है!

मैंने फाइलसिस्टम के साथ रूटिंग पर कुछ

• [param] सबसे सुरक्षित प्रतीत होता है (और इसका उपयोग सैपर द्वारा किया जाता है)।
• : एक्सप्रेस उपयोगकर्ताओं के लिए परिचित है, लेकिन मैं _sworn_ सकता है मेरे पास Windows FS पर समस्याएँ थीं।
• $ और {param} का उपयोग गोले में चर और ब्रेस विस्तार के लिए किया जाता है, इसलिए यह CLI में होने पर अधिक समस्याग्रस्त हो सकता है।
• _ _could_ काम करते हैं, लेकिन यह "निजी" संकेतक के रूप में बहुत आम है।

मेरे पास मार्गों के लिए व्यक्तिगत रूप से श्वेतसूची फ़ाइलों ( /^index\. ) बनाम एक ब्लैकलिस्ट ( /^_/ ) के साथ बेहतर अनुभव है, लेकिन यह /pages साथ एक पश्चगामी संगतता समस्या होगी।

समर्थन एपीआई मार्गों (# 7297) के हाल के विचार विमर्श के साथ, इस का समर्थन करने के लिए एक अवसर हो सकता है /api और /pages दोनों का एक नया घर के तहत /routes ।

हालांकि, _और यह एक मजबूत "हालांकि" _ है, Next.js पारिस्थितिकी तंत्र वारंट _incremental_ सुविधा के परिवर्धन के लिए पर्याप्त है, बनाम एक "हे, अगर हमें इसे फिर से करना पड़ा तो हम इसे _thre_ way" डिजाइन करेंगे।

वर्ग कोष्ठक ( [example] ) का उपयोग पैटर्न मिलान के लिए zsh द्वारा किया जाता है, इसलिए यह व्यवहार्य भी नहीं होगा।

Filename जनरेशन में उदाहरण देखें

ब्रैकेट [] का उपयोग पैटर्न मिलान के लिए zsh द्वारा किया जाता है, इसलिए यह व्यवहार्य भी नहीं होगा।

ऐसा लगता है जैसे उन्होंने इसे सिर्फ https://github.com/zeit/next.js/pull/7623 में बनाया है

सर उठाने के लिए धन्यवाद। मैंने वहां एक टिप्पणी भी पोस्ट की।

मैंने [id] की कोशिश की और सिर्फ रास्तों में इसका उपयोग करना एक दर्द है (जैसे cd \[id\]/view.js )। मुझे डबल अंडरस्कोर __id (जैसे cd __id/view.js ) काम करता है और साथ ही आंतरिक फ़ाइलों / फ़ोल्डरों से (अल्बाइट शायद थोड़ा भ्रमित अभी भी) अलग किया जा सकता है (जैसे _app.js )।

@AaronDDM क्या आप zsh का उपयोग कर रहे हैं? आपको बैश में [ या ] बचने की आवश्यकता नहीं है।

हाँ, यह मेरे लिए भी होता है zsh - इन निर्देशिकाओं के साथ बातचीत करने के लिए सुपर कष्टप्रद।

$ mkdir [asdf]
zsh: no matches found: [asdf]
$ mkdir \[asdf\]
$ cd [asdf]
zsh: no matches found: [asdf]
$ cd \[asdf\]

और चूंकि zsh macOS कैटालिना में डिफ़ॉल्ट शेल बन जाएगा , शायद इस बारे में कुछ किया जाना चाहिए ...

__id.js सहमत हैं

हम्म, वास्तव में __ प्यार नहीं करते, बस मुझे बहुत अच्छा नहीं लगता।

@merelinguist em, __tests__ उपयोग करती है, मुझे लगता है कि किसी मामले में __ अर्थ है।

@YUFENGWANG शायद, लेकिन अगर संभव हो तो मैं एक एकल चरित्र पसंद करूँगा। अंत में, मुझे लगता है कि सबसे अच्छा समाधान होगा:

1. समझदार, क्रॉस-प्लेटफ़ॉर्म डिफ़ॉल्ट, जैसे =
2. next.config.js का विकल्प विशेष मार्ग के चरित्र को अनुकूलित करने के लिए उपयोग किया जाता है
3. किन स्थितियों में समस्याएँ हैं उन पर दस्तावेज़ीकरण

एक ही चरित्र के साथ सहमत है, लेकिन मैं एक शून्य विन्यास है पसंद करेंगे। और मेरा अनुमान है कि कई लोग सभी मुद्दों से गुजरेंगे, भले ही आप उन्हें एक दस्तावेज में वर्णित करें

नोट भी = zsh द्वारा आरक्षित है। डॉक्स से :

यदि कोई शब्द किसी अनछुए '=' अक्षर से शुरू होता है और एक्वाल्स विकल्प सेट होता है, तो शेष शब्द को एक कमांड के नाम के रूप में लिया जाता है। यदि कोई कमांड उस नाम से मौजूद है, तो शब्द को कमांड के पूर्ण पथनाम से बदल दिया जाता है।

एक विचार है; प्रत्यय का उपयोग करने के बारे में क्या? उदाहरण के लिए [email protected] , या जैसे पर्याप्त हो सकता है। जब तक चरित्र वैध है, तब तक गोले और फ़ाइल सिस्टम पर भागने और काम करने के साथ यह समस्या हल हो सकती है।

अब तक भागने की आवश्यकता के बिना zsh और bash में ये काम:

[email protected]
example~.js
example=.js

ऊह। एक प्रत्यय नहीं, बल्कि URL params अनुगामी का एक तरीका है।

तो [email protected] blog/:id हो जाता है।

compare@[email protected] compare/:a/:b हो जाता है।

यह गहरी नेस्टेड एकल फ़ाइल निर्देशिकाओं को हल कर सकता है जो मैं ऊपर आपत्ति कर रहा था, और संपूर्ण रूटिंग परिभाषा फ़ाइल सिस्टम को आधारित रखें।

यह कल्पना के रूप में नहीं दिखता है, लेकिन कैसे की तर्ज पर कुछ के बारे में:

/blogs/_var_blog-id/index.js
/blogs/_var_blog-id.js

एक उपसर्ग _var_ जेएस चर घोषणाओं की नकल करने की किस तरह की कोशिश करता है। या इसके लिए एक सुपर शॉर्ट, एक चरित्र वाली चीज होना जरूरी है?

~ चरित्र के बारे में कैसे?

जैसे /blogs/~id ।

उपसर्ग के रूप में ~ का उपयोग करना भी व्यवहार्य नहीं है, क्योंकि इसका उपयोग POSIX-compliant गोले में होम फ़ोल्डर में विस्तार करने के लिए किया जाता है।

कोई भी वर्ण जो [0-9a-zA-Z-._] (regex) से मेल नहीं खाता है, उसे ऑपरेटिंग सिस्टम, शेल और फ़ाइल सिस्टम में उपसर्ग के रूप में सुरक्षित नहीं माना जा सकता है।

कुछ वर्ण सुरक्षित इनलाइन नहीं हैं, या तो। प्रतिस्थापन के बारे में zsh के

इसके अलावा मुझे लगता है कि हमें इसके लिए प्रयास नहीं करना चाहिए कि यह फैंसी लग रहा है, बल्कि सहज, पठनीय और संवाद करने में आसान है।

• [params].js लिए कोष्ठक का उपयोग करना अधिक सुरुचिपूर्ण और व्यापक रूप से उपयोग किया जाता है। (सैपर, नुक्स्ट v3?)।
• अंडरस्कोर उपसर्ग pages/_helper.js आमतौर पर एक निजी फ़ंक्शन के लिए और शायद यह प्रदान नहीं किया जाना चाहिए। यह हमें पेज फोल्डर के भीतर सहायक घटक बनाने की अनुमति देता है

imho: यह अधिक से अधिक समस्या के लिए एक अस्थायी समाधान की तरह लगता है। फ़ाइल संरचना पर आधारित मार्ग होने के साथ शुरू करने के लिए बहुत अच्छा है, यह अच्छी तरह से पैमाने पर नहीं होता है जब आपके पास सैकड़ों मार्ग, परम आदि होते हैं, तो मार्ग कॉन्फ़िगर फ़ाइल होती है (हो सकता है कि प्रत्येक निर्देशिका में एक मार्ग। जेएस फ़ाइल हो) एक बेहतर दीर्घकालिक समाधान है। मैं व्यक्तिगत रूप से अगली पीढ़ी के लिए तैयार हूं क्योंकि यह आउट-ऑफ-द-बॉक्स (SSR, गति, आदि) सुविधाओं के कारण प्रदान करता है, न कि फाइलों से मार्ग बनाने में आसानी।

@ ममहलवी आपने सिर पर कील ठोक दी।

Next.js पहले से ही रूट कॉन्फिग (फाइलसिस्टम के आधार पर) उत्पन्न करता है। मेरा मानना ​​है कि इस विन्यास को और अधिक स्पष्ट और / या उपयोगकर्ता को "बेदखल" करने की अनुमति देता है अगर वे चाहें तो यहां सबसे सहज समाधान होगा।

@mmahalwy @ scf4 FWIW,

रूट कॉन्फिगरेशन के साथ समस्या यह है कि आप इसे क्लाइंट को शिप करने के लिए समाप्त कर देते हैं, जिसका अर्थ है कि यदि आप सैकड़ों से हजारों की संख्या में रूट करते हैं, तो काफी भारी कोड बंडल हो सकता है।

हालाँकि, कुछ सामान्य उपयोग के मामले हैं जो (जहाँ तक मैं बता पा रहा हूँ, पिछले कुछ महीनों में कई बार @timneutkens के साथ इस मुद्दे पर चर्चा करने से) वास्तव में एक केंद्रीकृत विन्यास के बिना हल नहीं किया जा सकता है। मैंने उनमें से कुछ को अपनी पिछली टिप्पणी में सूचीबद्ध किया है, लेकिन और भी हैं।

सबसे सरल एक सीएमएस-संचालित ब्लॉग है जहां लेखक साइट पर पृष्ठों के लिंक बना सकते हैं। वे केवल सादे पुराने URL के साथ लिंक बना रहे होंगे, जिसमें अंतर्निहित पृष्ठ मॉड्यूल का कोई ज्ञान नहीं होगा। एक केंद्रीकृत मार्ग विन्यास के साथ, एक यूआरएल से मिलान करना और पेज लोड करने के लिए बहुत आसान है (मेरा अपना पुस्तकालय, अगला मार्ग-रिज़ॉल्वर इस उपयोग के मामलों का समर्थन करने के लिए डिज़ाइन किया गया है, और सभी अन्य जो मैं साथ आया हूं) ।

मैं यह नहीं देखता कि बिना रूट कॉन्फिगर के मैं जिस साइट पर काम कर रहा हूं, उसे मैं कैसे बना सकता हूं, इसलिए मेरा ध्यान सिर्फ फाइल को सहिष्णुता के भीतर रूट को कॉन्फिगर करने के तरीके खोजने पर रहा है। अन्य लोगों के लिए, फ़ाइल सिस्टम रूटिंग पर्याप्त से अधिक हो सकती है। मुझे नहीं लगता कि रूटिंग एक ऐसी समस्या है जहां एक ही समाधान है जो सब कुछ हल करता है, यह सब व्यापार-संतुलन को संतुलित करने के बारे में है।

इसलिए जैसा कि मैंने पहले उल्लेख किया है, जहां तक ​​इस प्रस्ताव का संबंध है, यह तब तक ठीक लगता है जब तक यह रूटिंग समस्या को पूरी तरह से हल करने के रूप में बेचा जाता है, क्योंकि यह थोड़ा भ्रामक होगा :)

@AndrewIngram मैं समझता हूं कि आप कहां से आ रहे हैं, लेकिन यह सीमा अगली शक्ति के पास सीमित है। Nextjs बॉक्स से इतना अधिक प्रदान करता है कि इसका उपयोग करने के लिए किसी भी नई परियोजना या कंपनी के लिए कोई दिमाग नहीं होना चाहिए। यह चुनौती हालांकि रूटिंग पर कड़ी राय है जो इसे भविष्य में अजेय बनाती है (और एक बड़ी कंपनी के रूप में, आप हमेशा इस बात पर विचार कर रहे हैं कि बाहर निकलने की रणनीति में परियोजनाओं को ब्याज या रखरखाव खो देना चाहिए)।

@ ममहलवी मुझे लगता है कि आपने मेरी बात को गलत समझा। मैं आपके साथ समझौता कर रहा हूं, मुझे नहीं लगता कि फ़ाइल-सिस्टम रूटिंग रूटिंग समस्या को हल करने के लिए पर्याप्त है, और यदि यह इस तरह प्रस्तुत किया गया तो निराश होगा। मुझे लगता है कि यह उपयोग के मामलों के एक विशेष सेट के लिए एक सुधार प्रदान करता है, लेकिन मुझे यह भी लगता है कि व्यापार-नापसंद के एक अलग सेट में ऑप्ट-इन करने के इच्छुक लोगों के लिए कुछ प्रकार के मार्ग प्रकट प्रारूप भी होने चाहिए (जैसे कि आप और मैं) ।

एक केंद्रीकृत या उन्नत मार्ग विन्यास की इच्छा रखने वालों के लिए, क्या यह कस्टम सर्वर और / या बाहरी पैकेजों का उपयोग करके अच्छी तरह से संभाला नहीं जाता है? आप यहाँ क्या उम्मीद कर रहे हैं?

यह सब इस RFC के विषय से हटकर लगता है। मुझे नहीं लगता कि ओपी सहित किसी ने भी सुझाव दिया है कि यह रूटिंग के लिए अंतिम समाधान है। यह सिर्फ फाइल सिस्टम आधारित रूटिंग में सुधार करता है।

मैं पिछले कुछ हफ्तों से एक मिनी परियोजना के लिए गतिशील मार्गों का उपयोग कर रहा हूं ( $ का उपयोग करते हुए हालांकि मैं ध्यान देता हूं कि यह कैनरी रेपो में 3 दिन पहले [param] स्थानांतरित हो गया है, लेकिन वैसे भी)।

I _just_ ने getRequestHandler का उपयोग करना शुरू किया और मुझे लगता है कि यह सर्वर साइड पर डायनेमिक रूटिंग को नहीं उठा रहा है।

क्या यह एक बग, या जानबूझकर (यानी कुछ getRequestHandler लिए कुछ परिवर्तन है), कुछ और, या getRequestHandler पूरी तरह से गतिशील रूटिंग को बंद कर देता है (जो अब समझ में आएगा कि मैं इसके बारे में सोचता हूं ...) ?

एक केंद्रीकृत या उन्नत मार्ग विन्यास की इच्छा रखने वालों के लिए, क्या यह कस्टम सर्वर और / या बाहरी पैकेजों का उपयोग करके अच्छी तरह से संभाला नहीं जाता है? आप यहाँ क्या उम्मीद कर रहे हैं?

यहां लक्ष्यों में से एक कस्टम सर्वर बनाने की आवश्यकता से बचने के लिए है, अगर केवल अब जैसी सेवाओं के साथ उपयोग करना आसान बनाने के लिए (जिसमें वर्तमान में सभी गतिशील मार्गों को इसके कॉन्फ़िगरेशन का हिस्सा होने की आवश्यकता है)।

यह सब इस RFC के विषय से हटकर लगता है। मुझे नहीं लगता कि ओपी सहित किसी ने भी सुझाव दिया है कि यह रूटिंग के लिए अंतिम समाधान है। यह सिर्फ फाइल सिस्टम आधारित रूटिंग में सुधार करता है।

वास्तव में यहाँ कुछ अतिरिक्त संदर्भ है। इस प्रस्ताव को आने में काफी समय हो गया है, और इससे संबंधित कई चर्चाओं के आधार पर (जिनमें मैं सीधे तौर पर शामिल हो चुका हूं), यह कुछ हद तक इन मार्ग का उपयोग करने की आवश्यकता को दूर करने के रूप में सम्मोहित किया जा रहा था। प्रबंधन पुस्तकालयों जैसे अगले-मार्ग और मेरे अपने। मुझे नहीं लगता कि इस RFC द्वारा उपयोग किए गए मामलों को पूरा करने के लिए यह ऑफ-टॉपिक है। उनमें से कुछ प्रस्ताव के कुछ बदलावों से संभवत: पूरी हो सकती हैं, अन्य नहीं। लेकिन किसी भी तरह से, निश्चित रूप से यह प्रस्तावित करने की सीमाओं के बारे में जागरूकता बढ़ाने के लिए मूल्यवान है?

FWIW हम Pinterest पर [param] शैली FS-आधारित मार्गों का उपयोग करते हैं (हालांकि अगला नहीं)। यह अब तक बहुत अच्छी तरह से बढ़ाया है। सबसे बड़ी आलोचना यह है कि जेस्ट रेपेक्स जोड़े के रूप में [] व्याख्या करता है,

@chrislloyd विभिन्न वातावरणों में पथ / फ़ाइलों के लिए इस प्रारूप का उपयोग करके फ़ाइलों को बनाने और प्रबंधित करने के बारे में आपके क्या अनुभव हैं, किसी को भी ज़ीश का उपयोग करने पर विचार करना चाहिए, या एक उपकरण जो इन विभिन्न तरीकों की व्याख्या करता है?

[] रूप में देखा जाता है, जो कि zsh में पैटर्न से मेल खाता है (और, जैसा कि आप जेस्ट के साथ कहते हैं) आपको इन रास्तों से बचना होगा। यदि आप _know_ यह समस्या है, लेकिन यह बहुत उपयोगी नहीं है, लेकिन यह बताया कि यह प्रयोग करने योग्य होना चाहिए और शुरुआती लोगों द्वारा समझा जाना चाहिए, मुझे संदेह है कि यह सही प्रारूप है।

मेरे पास आवश्यक पैरामीटर के रूप में ! का उपयोग करने पर एक विचार है, जैसे /pages/id!.js और ? वैकल्पिक पैरामीटर के लिए, जैसे /pages/posts/id?.js ।

उपर्युक्त चर्चाओं जैसे उपसर्ग के साथ इसका कोई मुद्दा नहीं है, और यह इस बात से परिचित है कि ! आवश्यक परिमों का प्रतिनिधित्व करता है, और ? वैकल्पिक मापदंडों का प्रतिनिधित्व करता है।

Windows फ़ाइल नामों और दोनों में प्रश्न चिह्न की अनुमति नहीं देता है? तथा ! बाश में एक विशेष अर्थ है।

API मार्ग अब गतिशील पैरामिक्स # 7629 dynamic का समर्थन करते हैं

@remy getRequestHandler गतिशील रूटिंग को संभालने के लिए अपेक्षित है - मैं स्थानीय रूप से इसकी पुष्टि करता हूं। क्या आप कृपया एक अलग बग दर्ज कर सकते हैं / प्रजनन कदम के साथ मुद्दा ताकि हम जांच कर सकें? :प्रार्थना करना:

हेलो सब लोग! इस RFC को अविश्वसनीय प्रतिक्रिया के लिए धन्यवाद।

इस RFC को Next.js 9 में स्थिर रूप में लागू और जारी किया गया है।
आप इसके बारे में ब्लॉग पोस्ट में अधिक पढ़ सकते हैं।

हम भविष्य में एक नया RFC प्रकाशित करने जा रहे हैं ताकि यहां दी गई सभी उन्नत प्रतिक्रिया को संबोधित किया जा सके। उपलब्ध होने पर हम यहां एक अपडेट पोस्ट करेंगे।