Next.js: रिएक्ट राउटर 4 के साथ प्रयोग करें

को निर्मित 5 अप्रैल 2017  ·  122टिप्पणियाँ  ·  स्रोत: vercel/next.js

क्या नई प्रतिक्रिया रूटर v4 के साथ next.js का उपयोग करना संभव है?

सबसे उपयोगी टिप्पणी

@timneutkens रिएक्टर राउटर इंटीग्रेशन को जोड़ने से नेक्सस गोद लेने और विकास को बेहतर बनाने में मदद मिलेगी। अपने जैसे देवों को ऐसा होते देखना अच्छा लगेगा, कृपया प्राथमिकता बढ़ाने पर विचार करें।

सभी 122 टिप्पणियाँ

@Knaackee क्या आपने संभावना की कोशिश की? मैं सोच रहा हूं कि क्या किसी ने आरआर के किसी भी संस्करण के साथ काम करने के लिए इसे प्राप्त किया है?

अगला का अपना राउटर है, आरआर का उपयोग क्यों करें?

@sergiodxa वजनी विकल्प के रूप में मैं अपने मौजूदा ऐप को नेक्स्ट में पोर्ट करता हूं। मेरे पास एक स्थिर, नेस्टेड मार्ग है जो काम कर रहा है और सोच रहा है कि मैं क्या उपयोग कर सकता हूं और क्या नहीं ..

@oyeanuj 🤔 आप धीरे-धीरे नेक्स्ट में माइग्रेट कर सकते हैं, बस Next.js को 1 रूट को सेट करने के लिए सेट करें और अपने वर्तमान ऐप और Next.js दोनों के लिए एक प्रॉक्सी का उपयोग करें, फिर RR से नेक्स्ट.जेएस के लिए एक दूसरा रूट स्थानांतरित करें, और वह जिस तरह से आप अपने वर्तमान एप्लिकेशन को माइग्रेट करते समय रख सकते हैं, अंततः आपके पास Next.js में सब कुछ होगा

उदाहरणों को देखने से ऐसा लगता है कि अगले में RRv2-3 की तरह एक एकल मार्ग तालिका है और RRv4 की तरह "नेस्टेड मार्गों" का समर्थन नहीं करता है। ये अच्छे हैं।

मैं आरआर का उपयोग करने की कोशिश करूंगा या क्या मुझे पता नहीं है कि एक बड़ा चेतावनी है?

@igl क्या आपने

नेस्टेड मार्गों का नया रिएक्टर-राउटर 4 प्रतिमान एक गेम-चेंजर है, और हमारे वर्तमान प्रोजेक्ट में कुछ होना चाहिए। मैं सोच रहा था कि क्या किसी ने rr4 प्राप्त करने में कामयाबी हासिल की है।

MemoryRouter काम करता है, यदि इरादा नहीं है ...
अन्यथा, गतिशील घटक केवल क्लाइंट-साइड हो सकते हैं, जहां HashRouter ठीक काम करता है ...

const AdminPage = dynamic(
  import('..../AdminPage'),
  { ssr: false }
);

मैं react-router साथ @malixsys दृष्टिकोण और क्लाइंट साइड रूटिंग का अनुसरण कर रहा हूं और सभी सर्वर ने next राउटर के साथ सामग्री प्रदान की है।

@malixsys @pegi स्वर्ग यू अगले राउटर और प्रतिक्रिया-राउटर को एक साथ उपयोग करने के लिए कुछ और विवरण दे सकता है?

आप में एक ध्वज सेट कर सकते हैं componentDidMount और सशर्त प्रस्तुत करना <Router /> जब झंडा truthy है। ( componentDidMount सर्वर on पर नहीं चलता है)

वास्तव में, हम Next.js के अंदर React Router को जल्द ही शामिल कर रहे हैं :)
- https://twitter.com/rauchg/status/948318111828099072

क्या अब भी ऐसा हो रहा है? मैं वी 6 कैनरी के रिलीज़ नोट देख सकता हूं और इसका कोई उल्लेख नहीं है।

अंततः। यह निश्चित रूप से हमारे दिमाग में है। हमें अभी अन्य प्राथमिकताएं मिली हैं (लेआउट घटक, विश्वसनीय विकास और कुछ अन्य लंबे समय तक खुले मुद्दे)।

यह एक शर्म की बात है, यह टीम के लिए कम प्राथमिकता हो सकती है, लेकिन मूल रूप से यह एकमात्र चीज है जो मेरे जैसे लोगों को इसका इस्तेमाल करना शुरू करने से रोक रही है। मैं आपके ट्यूटोरियल को तब तक पढ़ता हूं जब तक कि मैं बिट के पास नहीं पहुंच गया, जहां उसने कहा कि मार्गों को दो बार स्थापित किया जाना है, फिर छोड़ दिया।

@timneutkens रिएक्टर राउटर इंटीग्रेशन को जोड़ने से नेक्सस गोद लेने और विकास को बेहतर बनाने में मदद मिलेगी। अपने जैसे देवों को ऐसा होते देखना अच्छा लगेगा, कृपया प्राथमिकता बढ़ाने पर विचार करें।

यह एक शर्म की बात है, यह टीम के लिए कम प्राथमिकता हो सकती है, लेकिन मूल रूप से यह एकमात्र चीज है जो मेरे जैसे लोगों को इसका इस्तेमाल करना शुरू करने से रोक रही है।

वही।

क्या हम कम से कम इस मुद्दे को फिर से खोल सकते हैं ताकि इसे ट्रैक किया जा सके?

मैं इसे फिर से खोलने जा रहा हूं, लेकिन ध्यान दें कि यह एक ओपन सोर्स प्रोजेक्ट है और zeit.co के लिए इस समय हमारे पास इसके लिए बहुत मजबूत मामला नहीं है, क्योंकि हम सब कुछ के लिए Next.js का उपयोग करते हैं।

यही कारण है कि मैं कह रहा था कि यह लंबी अवधि के लक्ष्यों का हिस्सा है और इसे तुरंत लागू नहीं किया जा सकता है, लेकिन हम इसके लिए काम कर रहे हैं।

जिन विशेषताओं को मैं नेक्स्ट 6 में पेश कर रहा हूं, वे वास्तव में रिएक्ट राउटर सपोर्ट की दिशा में काम कर रही हैं।

अगले 6 के लिए हमारे पास अन्य प्राथमिकताएं थीं, जो नेक्स्ट.जेएस की विश्वसनीयता और स्केलेबिलिटी में काफी सुधार कर रही हैं, उदाहरण के लिए 100x तेज पृष्ठ का समाधान, ऐप कंपोनेंट, विकास में अगला निर्यात कार्य करना, बैबल 7, आदि।

मुझे आशा है कि यह मेरी पूर्व टिप्पणी पर विस्तृत है।

तो TLDR है:

  • हम इसे करने जा रहे हैं, लेकिन तुरंत नहीं
  • अगले 6 में नेक्स्ट.जेएस के विभिन्न हिस्सों में कई सुधार हैं

@Timneutkens की टिप्पणी को आगे बढ़ाने के लिए: हम निश्चित रूप से आरआर चाहते हैं, लेकिन वर्तमान राउटर में हमारी कोई दबाव सीमाएं नहीं हैं जो इसे प्राथमिकता देते हैं। सभी रूटिंग उपयोग-मामलों की आप कल्पना कर सकते हैं जो वर्तमान Next.js API के साथ सफलतापूर्वक लागू किए गए हैं

दो कारण हैं जो हम वास्तव में प्रतिक्रिया रूटर समर्थन चाहते हैं :

  • अपने स्वयं के Next.js कोडबेस को सरल बनाएं, हमारे स्वयं के राउटर को बनाए रखने के लिए नहीं है, चीजों को छोटा और मॉड्यूलर बनाएं
  • आरआर का उपयोग करके पहले से ही बड़े अनुप्रयोगों के माइग्रेशन पथ को सरल बनाएं

जैसे, मैं मानता हूं कि हमें इस मुद्दे को खुला रखना चाहिए!

काउंटरपॉइंट के रूप में, प्रतिक्रिया-राउटर नहीं होने का मतलब है कि अगला रिले-आधुनिक के साथ अच्छी तरह से काम करता है और एक कारण था जिसे हमने अपने पुराने प्रतिक्रिया-राउटर ऐप से अगले में बदल दिया था।

@merrywhether मैंने पिछले साल रिले-आधुनिक के साथ एक RRv4 ऐप पर काम किया। अधिक विशिष्ट होने के लिए देखभाल?
मुझे याद नहीं है कि हमें या तो गंभीर मुद्दे हैं।

@igl यह रिले के प्रलेखन के अनुसार है: https://facebook.github.io/relay/docs/en/rout.html#react -router-https-reacttrainingcom-react-रूटर

समस्या यह है कि आरआरवी 4 का घटक दृष्टिकोण पूर्व-संकलन कदम के दौरान निर्धारण के लिए अनुमति नहीं देता है, जिसके परिणामस्वरूप क्लाइंट में अनुरोध झरने हो सकते हैं।

@ रुचग आउट ऑफ इंटरेस्ट, नेक्स्ट के राउटर के बारे में मेरी समझ यह है कि यह नेस्टेड रूटिंग की अवधारणा का समर्थन नहीं करता है, इसलिए आप एक पेज के भीतर नेविगेट करते समय बाहरी मार्कअप रख सकते हैं। क्या आप जानते हैं कि वर्तमान राउटर के साथ इसे संभव बनाने का कोई तरीका है?

@dbbk हमारे अगले उदाहरण उदाहरण ऐप (https://github.com/now-examples/nextgram) की जाँच करें, यह ऐसा करता है

अगले 5 में, हम शीर्ष-स्तरीय लेआउट घटकों के द्वारा "बाहरी मार्कअप" को पूरा कर रहे हैं, जो हमारे सभी पृष्ठों का विस्तार करते हैं: आधार लेआउट में शीर्ष नौसेना है, फिर कुछ उप-लेआउट जो सूची / विवरण / आदि के लिए आधार का विस्तार करते हैं, और फिर हमारे पृष्ठ घटक अपनी विशिष्ट सामग्री के साथ इन उप-लेआउट का विस्तार करते हैं। अगले 6 में, आप _app.js मेरा विश्वास करते हुए मूल "बाहरी मार्कअप" को भी पूरा कर सकते हैं।

क्या अगला संस्करण एक राउटिंग समाधान चुनने के लिए कॉन्फ़िगर किया जा सकता है जो कि रिएक्ट राउटर नहीं है?

हाय, मैं केवल क्रम में रूटर प्रतिक्रिया की जरूरत है पृष्ठों के लिए रंगमंच की सामग्री (का उपयोग कर पारित करने के लिए <Route render ={} /> के बजाय <Route component ={} /> ), मैं इसे अगले के साथ क्या कर सकते हैं?

उदाहरणों को देखने से ऐसा लगता है कि अगले में RRv2-3 की तरह एक एकल मार्ग तालिका है और RRv4 की तरह "नेस्टेड मार्गों" का समर्थन नहीं करता है। ये अच्छे हैं।

नमस्ते,

क्या इसका मतलब है कि मुझे एकल मार्ग के लिए एक पृष्ठ बनाना होगा?

मान लीजिए कि मेरे पास 2 मार्ग sign up , log in । मेरे पास 1 पेज होगा जो समान लेआउट को साझा करता है, केवल अंतर रूपों का क्षेत्र है। मुझे सिर्फ pages फ़ोल्डर में 1 फ़ाइल बनाने की आवश्यकता है। लेकिन अगले रास्तों से मुझे pages फ़ोल्डर में 2 फाइलें बनानी होंगी। क्या यह?

यदि यह है, तो लेआउट को हर नेविगेशन के साथ रिमाउंट किया जाता है, न कि केवल फॉर्म एरिया, राइट?

@ 7c78 एक बात जो आप कर सकते हैं वह है सभी पेजों के लिए लगातार पेज लेआउट के लिए _app.js का लाभ उठाना। दूसरी बात यह है कि साझा किए गए लेआउट घटक बनाने के लिए जिसे आप देख रहे हैं, उसे प्राप्त करने के लिए आप विभिन्न पृष्ठों में पुन: उपयोग कर सकते हैं:

// pages/login.js

class LoginPage extends React.Component {
  render() {
    return (
      <AuthForm>    // same component can be reused in signup
        <form>
          ...implementation of login
        </form>
      </AuthForm>
    );
  }
}

इसके अतिरिक्त, आप कर सकते हैं कि हमने हाल ही में क्या किया है और आधार लेआउट घटकों को परिभाषित करें जो आपके पृष्ठ घटकों को बढ़ाते हैं:

//layouts/baseAuth.js

class BaseAuth extends React.Component {
  abstract formContent();  // we use typescript, but you can have the same concepts
  abstract formSubmit():

  render() {
    return (
      <SomeStyledDiv>
        <form>
          {this.formContent()}
          {this.formSubmit()}
        </form>
      </SomeStyledDiv>
    );
  }
}

और फिर आप बस अपने लॉगिन और साइनअप पृष्ठों में बेसऑथ का विस्तार करते हैं और उनमें से प्रत्येक में formContent और formSubmit परिभाषित करते हैं (ये खिलौना उदाहरण हैं, क्योंकि मैं आपको सटीक आवश्यकताओं को नहीं जानता हूं)।

@merrywhether
मैं वर्तमान में आपके दृष्टिकोण का उपयोग करता हूं, और अगले उदाहरण भी इसका उपयोग करते हैं।

लेकिन मेरी चिंता यह है कि मुझे अलग-अलग फॉर्म के लिए अलग पेज बनाने की जरूरत है। यह लेआउट फिर से उपयोग किया जाता है, लेकिन पृष्ठ नहीं। और लेआउट को हर नेविगेशन के साथ रिमाउंट किया गया है।

आरआरवी 4 के साथ, हमारे पास एकल पृष्ठ हैं और मार्गों के आधार पर रूपों का प्रतिपादन / ब्योरा दिया जाता है (पूरे पृष्ठ पर नहीं)। रूट सिर्फ घटक हैं।

तेजी से प्रतिक्रिया के लिए धन्यवाद!

@ 7c78 यह

यह ऐसा कुछ नहीं है जिसके साथ हम सुपर चिंतित हैं क्योंकि हम रिले-आधुनिक के साथ प्रतिक्रिया-राउटर का उपयोग नहीं कर सकते हैं, इसलिए हमें इस पैटर्न का उपयोग करना होगा।

@merrywhether मुझे

मैं सहमत हूं कि हमें इस पैटर्न का उपयोग वैसे भी करना है। धन्यवाद!

आप अपने संपूर्ण ऐप को पृष्ठों / index.js में होने के द्वारा अगली बार आरजे के साथ आरआर का उपयोग कर सकते हैं। लेकिन आप अगले कुछ अच्छाइयों को खो देते हैं जैसे कि बॉक्स कोड को विभाजित करना और खुद को स्थापित करना है।

यदि रीच राउटर माना जाता तो मुझे अच्छा लगता। यह प्रतिक्रिया-राउटर के समान है और कुछ महत्वपूर्ण लाभ लाता है:

  • यह लिंक जनरेशन और फ़ोकस मैनेजमेंट (https://reach.tech/router/accessibility) के आसपास कुछ महत्वपूर्ण a11y चिंताओं को हल करता है।
  • इसका वजन कम होता है (लेखन के समय)

रीच राउटर भी बहुत अच्छा है

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

@sorokinvj यह केवल एक प्लगइन (वर्तमान में) के माध्यम से समर्थित है .. https://github.com/fridays/next-routes

स्थैतिक लिंक इतने बुनियादी हैं कि यह लिंक में मापदंडों का समर्थन भी नहीं करता है ...

मैं अब इसके लिए प्राप्त करने के लिए https://github.com/fridays/next-routes के लिए थर्ड पार्टी पैकेज का उपयोग कर रहा हूं

मेरे आईफोन से भेजा गया

24 अक्टूबर 2018 को, 23:01 पर, एंडी इनग्राम नोटिफिकेशन @github.com ने लिखा:

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपको इस धागे की सदस्यता दी गई है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

हम समय-समय पर next-routes का उपयोग कर रहे हैं, लेकिन मेरा मानना ​​है कि अगली टीम regex फ़ाइल नामों (सैपर द्वारा प्रेरित) के माध्यम से अपने फ़ाइल-सिस्टम रूटिंग में पथ पैरामीटर को जोड़ने पर काम कर रही है।

@merrywhether मैं next-routes का उपयोग कर रहा हूं, लेकिन यह Next.js कोर का हिस्सा होगा।

आपने उल्लिखित किया था

मेरा मानना ​​है कि अगली टीम पथ मापदंडों को जोड़ने पर काम कर रही है ...

मैं उत्सुक हूँ क्या आपके पास इसके लिए कोई संदर्भ है? शायद मार्ग मापदंडों के लिए एक खुला मुद्दा? मैं एक खोजने में सक्षम नहीं हूँ ... शायद प्लगइन की आवश्यकता को हल करता है और यह अनुशंसित समाधान आगे बढ़ेगा।

@curran स्रोत

इस मुद्दे को 5 अप्रैल, 2017 को उठाया गया था और अब 27 फरवरी, 2019 है। लगभग 2 साल और कोई समाधान नहीं है
कुछ अच्छे के साथ अर्ध-निर्मित बिल्ट-इन राउटर को बदलने का समय हो सकता है?

आउच। यह NextJS देवताओं के लिए काफी अपमानजनक है जिन्होंने कई घंटे रूटिंग समाधान में डाल दिए।

मैं पहली बार में ReactRouter से चूक गया। अब मुझे यह भी याद नहीं है कि NextJS के पास एक अलग राउटर है जब तक कि कोई मुझे याद न दिलाए। Verbose Link API उदाहरण के लिए परदे के पीछे (अपने डेटा / एपीआई वास्तुकला के आधार पर) के साथ लपेटने के लिए तुच्छ है। इस शीर्ष रहस्य को साझा करना::

import _Link from "next/link"
export function Link({as, children, href}) {
  as = as || QS.parse(U.parse(href).query || "").url || null // QS, U are parsing libs
  return <_Link as={as} href={href}>
    {children}
  </_Link>
}
<Link as="/about" href="/page?url=/about"/> verbose
→
<Link href="/page?url=/about"/> ok

मुझे लगता है कि हम सभी को माध्यमिक सामान ing के बारे में शिकायत करने के लिए कम समय बिताना चाहिए

@ ivan-kleshnin नाइस मैंने एक समान आवरण जोड़ा

पिछली टिप्पणी के अनुसार मैं https://www.contributor-covenant.org/version/1/4/code-n-chaduct को इंगित करना चाहूंगा

मैंने कहा टिप्पणी छिपाई है।

मुझे ज्यादातर उपयोग के मामलों के लिए next/router कोई समस्या नहीं है।
लेकिन यह universal routing हिस्से पर थोड़ा सुधार होना चाहिए।
अब 2 तैनाती के मामले में, मैं सिर्फ now.json करूंगा और इसे अपने एप्लिकेशन में रूट करने के लिए उपयोग करूंगा।

यदि आप अगली परियोजना में RR4 को लागू करना चाहते हैं, तो आपको 2 काम करने होंगे:

  1. NextJS SSR को रोकें, next/dynamic का उपयोग करके आप ऐसा कर सकते हैं।
  2. HashRouter उपयोग करने के बजाय BrowserRouter -> यदि उपयोगकर्ता पृष्ठ पुनः लोड करता है, तो ब्राउज़र पिछले पृष्ठ को लोड कर सकता है (404 पृष्ठ नहीं)

यदि आप अगली परियोजना में RR4 को लागू करना चाहते हैं, तो आपको 2 काम करने होंगे:

  1. NextJS SSR को रोकें, next/dynamic का उपयोग करके आप ऐसा कर सकते हैं।
  2. HashRouter उपयोग करने के बजाय BrowserRouter -> यदि उपयोगकर्ता पृष्ठ पुनः लोड करता है, तो ब्राउज़र पिछले पृष्ठ को लोड कर सकता है (404 पृष्ठ नहीं)

इस उत्तर के लिए धन्यवाद, मेरी बहुत मदद की।

@ पहुंच / राउटर और प्रतिक्रिया-राउटर 5 विलय कर रहे हैं: https://reacttraining.com/blog/reach-react-router-future/

यह आगे कैसे प्रभावित करता है।

@ alp82 चूंकि Next.js अभी भी रिएक्ट राउटर या रीच राउटर का उपयोग नहीं करता है, यह Next.js को बिल्कुल भी प्रभावित नहीं करेगा।

मैं सूचकांक पृष्ठों में कई पृष्ठों के घटकों को प्रस्तुत करने के लिए नेक्स्ट में स्विच मार्गों की कार्यक्षमता की आवश्यकता है।
तो मैं इसे अगली बार कैसे लागू कर सकता हूं ....... ???

यदि आप अगली परियोजना में RR4 को लागू करना चाहते हैं, तो आपको 2 काम करने होंगे:

  1. NextJS SSR को रोकें, next/dynamic का उपयोग करके आप ऐसा कर सकते हैं।
  2. HashRouter उपयोग करने के बजाय BrowserRouter -> यदि उपयोगकर्ता पृष्ठ पुनः लोड करता है, तो ब्राउज़र पिछले पृष्ठ को लोड कर सकता है (404 पृष्ठ नहीं)

यदि आप अपने पिछले पृष्ठ को फिर से प्रस्तुत करना चाहते हैं तो बिना 404 त्रुटि के फेंक दें, ताकि यह आपके एक्सप्रेस सर्वर फ़ाइल में रूट प्राप्त कर सके।

server.get ('अपने परम', (पुनः, Res) => {
कॉन्स्ट एक्चुअलपेज = '/ your_page'
const क्वेरीपराम = {आईडी: req.params.id}
app.render (req, res, realPage, queryParams)
})

मैं उपयोग करने के लिए एक दृष्टिकोण दस्तावेज next.js के साथ react-router , एक एकल प्रवेश बिंदु फ़ाइल के बजाय देशी फाइल सिस्टम आधारित रूटिंग और पूरी तरह से देशी एसएसआर सुविधाओं

मुझे फीडबैक प्राप्त करने और मेरे द्वारा किए गए सुधारों पर खुशी होगी।

प्रलेखन इस प्रकार उपलब्ध है:

चीयर्स!

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

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

@timneutkens , मैं यहाँ एक तर्क शुरू नहीं करूँगा लेकिन मैं आपसे अपनी टिप्पणी अन-हाइड करने के लिए कहूँगा। मैंने अपना काम उपलब्ध करने और समुदाय को वापस देने के लिए समय बिताया और मैं यह नहीं देखता कि लोगों को चुप कराने से स्रोत विकास में मदद मिल सकती है।

@timneutkens आपके द्वारा बताए गए बिंदुओं के लिए यह एक व्यापार-नापसंद मामला है। मेरा एक प्रयोग है जो यह बताता है कि Next.js को एक अलग सेटअप के साथ कैसे इस्तेमाल किया जा सकता है।

क्लाइंट-साइड पर बहुत अधिक कोड

कोई भी आधुनिक बंडल क्लाइंट संपत्तियों को विखंडू में विभाजित कर सकता है और react-router मार्ग वास्तव में बहुत सुविधाजनक विभाजन बिंदु हैं।

उच्च देव निर्माण समय

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

कोई स्थिर निर्यात नहीं

मैं मानता हूं कि स्थिर निर्यात एक महत्वपूर्ण अनुकूलन परत है। अगले Next.js एप्लिकेशन द्वारा दिए गए अधिकांश पृष्ठों को वैसे भी गतिशील डेटा प्राप्त करना होता है और यह स्थिर निर्यात का लाभ नहीं दे सकता है।

इस चिंता के समाधान की कोई कमी नहीं है। उदाहरण के लिए। यह अभी भी मैन्युअल रूप से निर्यात किए जाने वाले मार्गों की सूची को मैन्युअल रूप से घोषित करना संभव हो सकता है

मेरे द्वारा टिप्पणी को छिपाने का कारण यह है कि यह एक उच्च ट्रैफ़िक समस्या है और यह Next.js ऐप्स के निर्माण के लिए हमारी सिफारिश को नहीं दर्शाता है। यदि कोई व्यक्ति प्रतिक्रिया-राउटर का उपयोग करने के लिए यहां समाप्त होता है, तो वे आपके उदाहरण का उपयोग करते हुए नेत्रहीन रूप से समाप्त हो जाएंगे और यह जांच नहीं करेंगे कि Next.js. का उपयोग करके राउटिंग को ठीक से कैसे सेट किया जाए।

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

आप अपने दृष्टिकोण के आधार पर देव-टाइम बूटअप को गति नहीं दे सकते हैं, वेबपैक कॉन्फ़िगरेशन की कोई विशिष्ट फाइन-ट्यूनिंग नहीं है क्योंकि वेबपैक बस हर एक मार्ग को संकलित और देखेगा जिसे आप आयात करते हैं जो बड़े पैमाने पर आम घटकों के संपादन को धीमा कर देता है। इसीलिए Next.js की ऑन-डिमांड-प्रविष्टियाँ हैं: https://nextjs.org/blog/next-8#improved -on-demand-प्रविष्टियाँ

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

मुझे यह टिप्पणी करने में कोई आपत्ति नहीं है कि अगर यह ठीक से यह दर्शाता है कि आप इसका उपयोग करना चाहते हैं, तो केवल उस ऐप को माइग्रेट करना है जो पहले से ही प्रतिक्रिया-राउटर का उपयोग कर रहा है और फिर धीरे-धीरे कई पृष्ठों पर चला जाता है।

अरे @timneutkens
क्या आप ऐसे कुछ पेशेवरों की गणना करेंगे, जो सांख्यिकीय रूप से एनालिसिस होने से टेबल पर आते हैं और डायनामिक रूटिंग समाधानों के साथ संभव नहीं हैं?

कुछ इस तरह की बातें https://github.com/jaredpalmer/after.js ?

Ive ने सभी टिप्पणियों को पढ़ा और अभी भी स्पष्ट नहीं है कि क्या भविष्य में RR4 + को शामिल किया जाएगा या भविष्य के पुनरावृत्तियों में वैकल्पिक होगा। क्या एक राउटर रोडमैप या कुछ इसी तरह का है?

@laurencefass ऐसा लगता है कि react-router (आज के अनुसार) का समर्थन करने की कोई योजना नहीं है।

मेरे लिए, Next.js का रूटिंग सिस्टम काफी परिपक्व होता जा रहा है, इसलिए हमें शायद (अब) वैसे भी इसकी आवश्यकता नहीं है :)

"मेरे लिए, Next.js का रूटिंग सिस्टम काफी परिपक्व हो रहा है, इसलिए हमें शायद (अब) वैसे भी इसकी आवश्यकता नहीं है :)"

एक मौजूदा कोडबेस में नेक्स्ट.जेएस को अपनाने की मांग करने वालों को छोड़कर। मुझे लगता है कि अधिक उपयोगी चर्चा संभवतः "Next.js रूटिंग बनाम प्रतिक्रिया-राउटर रूटिंग" नहीं है। मुझे लगता है कि अधिक उपयोगी चर्चा है "मैं नेक्स्ट.जेएस, इंक्रीमेंटल रूप से रिएक्टर-राउटर का उपयोग करके एक विशाल ऐप को कैसे माइग्रेट कर सकता हूं?"

अगले राउटर में मार्ग विचारों को घोंसला बनाने की क्षमता नहीं है, हालांकि, यह करता है? एक मार्ग के लिए हर नेविगेशन डोम को उड़ा देता है और इसे ताज़ा करता है। नेस्टेड विचार एक बहुत ही सामान्य आवश्यकता है।

@dbbk मैंने सुना कि नेक्स्ट की टीम इस पर काम कर रही है।

अगले जे एस रूटर्स के साथ बहुत लचीला है। https://dev.to/toomuchdesign/next-js-react-router-2kl8

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

अब एसईओ उद्देश्य के लिए, क्योंकि मेरे पास Google खोज से कुछ अच्छे ट्रैफ़िक हैं, मुझे इसे बनाए रखने की आवश्यकता है। इसलिए मैं बेहतर प्रदर्शन के लिए Next.js के साथ SSR को तरजीह दूंगा।

क्या Next.js सर्वर साइड पर किसी पेज को रेंडर करने में सक्षम है और फिर क्लाइंट साइड में एक बार पेज लोड हो जाता है, Next.js नेविगेशन को रिएक्ट राउटर नियंत्रण के तहत करने देगा, ताकि यदि उपयोगकर्ता संगीत सुन रहा है, तो Next.js लिंक जीता ' t संगीत बंद करने के लिए वर्तमान पृष्ठ छोड़ना होगा?

O. Next.js केवल क्लाइंट-साइड रूटिंग बना सकता है?

यदि रिएक्ट राउटर को एकीकृत करने से इसे हल किया जा सकेगा, तो मैं अंदर हूं। क्योंकि ऐप के क्लाइंट साइड में पहुंचने के बाद कंटीन्यूअस म्यूजिक प्लेइंग मेरे लिए बहुत जरूरी है।

अगले जे एस रूटर्स के साथ बहुत लचीला है। https://dev.to/toomuchdesign/next-js-react-router-2kl8

@laurencefass , यह एक बहुत अच्छा तरीका है, मैंने इसे पहले पढ़ा था। और लेख कहता है कि Next.js टीम इसकी अनुशंसा नहीं करती है, पता नहीं क्यों। लेकिन यह मुझे अच्छा लगता है

@KeitelDOG के लिए आपको प्रतिक्रिया-राउटर की आवश्यकता नहीं है, Next.js रूटिंग आपको समान लाभ लाएगा, साथ ही आपका ऐप ऑटोमैटिक कोड स्प्लिटिंग के लिए हल्का हो जाएगा (यह कि आप रिएक्टर-राउटर के साथ आसानी से नहीं होंगे)

_edit: मैं बस इसे जोड़ूंगा: शायद प्रतिक्रिया-राउटर का एकमात्र लाभ एक ही दृश्य सुविधा में आसान नेस्टेड मार्ग हैं, Next.js राउटर को आपके usecases_ का 95% हल करना चाहिए

@martpie प्रतिक्रिया के लिए धन्यवाद, यही मैंने कल रात Link घटक के साथ देखा। तब Next.js मिक्स सर्वर-क्लाइंट है जो मुझे चाहिए था।

और गतिशील रूप से अपने स्वयं के नेस्टेड मार्गों को नियंत्रित करने वाले घटक के लिए, मैं वास्तव में रिएक्ट राउटर के साथ इसे पसंद करता हूं। लेकिन मुझे पूरा यकीन है कि मुझे एक काम मिल सकता है, क्योंकि मैं एक रिएक्ट वेबसाइट को नेक्स्ट.जेएस में नहीं बदल रहा हूं, बल्कि एक जेएस - jQuery वेबसाइट को अपने एसईओ फायदे खोए बिना एक रिएक्ट मल्टी पेज एप्लिकेशन में बदलने की योजना और परीक्षण कर रहा हूं। Google पर इसलिए मुझे लगता है कि मुझे Next.js के साथ जाना चाहिए

@timneutkens Next.js 10 में इसका समर्थन करने की कोई योजना है?

@TrejGun धन्यवाद, यह निश्चित रूप से विषय नहीं है।

कोई योजना है?
next/router महान है, यह बहुत सहायता प्रदान करता है। लेकिन हमें जटिल अनुप्रयोगों का सामना करने के लिए अधिक पेशेवर राउटर की आवश्यकता है। प्रतिक्रिया-राउटर राउटर में एक नेता है।
शायद after.js को संदर्भित कर सकते हैं।

हाँ, यह पृष्ठ आधारित प्रणाली जटिल डेटा संचालित अनुप्रयोगों को संभालने के लिए पर्याप्त रूप से परिष्कृत नहीं है जो नेस्टेड मार्गों से लाभान्वित हो सकते हैं।

रिएक्ट-राउटर v6 संस्करण लॉन्च करने वाला है, जो अब तक का सबसे अच्छा राउटर होगा। मैं next.js समर्थन कर रहा हूँ।

एक बेहतर तरीका next.js और router , जिससे लोग अपने पसंदीदा router स्वतंत्र रूप से चुन सकें।

पिछली टिप्पणी के लिए +1। अगली .js अद्भुत है इसका एकमात्र कारण है कि मैं इसका उपयोग नहीं कर रहा हूँ यह राउटर पर लचीलेपन की कमी है। कृपया भविष्य के रिलीज़ में प्रतिक्रिया राउटर 6 का समर्थन करें या राउटर को स्वैपेबल बनाएं।

लोग वास्तव में रिएक्टर राउटर के लिए उत्सुक थे, नई परियोजना "रीमिक्स" का पालन करने में रुचि हो सकती है, यह एक अगला.जेएस विकल्प है जो एक ही रचनाकारों द्वारा रिएक्ट राउटर का उपयोग करता है:

मुझे लगता है कि समस्या यह है कि SSR, सर्वर साइड प्रॉप्स आदि के कारण फ्रेमवर्क उस राउटर से गहराई से बंधा हुआ है।

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

यही कारण है कि रिले प्रतिक्रिया-राउटर के साथ संगत नहीं है, और आप facebook.com पर एक जटिल वेबसाइट नहीं होने का आरोप लगा सकते हैं।

नेक्स्ट राउटर के साथ काम करने के लिए मुख्य सफल रणनीति कंपोजिबिलिटी (जो कि आधुनिक रिएक्ट में वैसे भी ड्राइविंग ट्रेंड है) में झुकाव है, जिससे आप प्रमुख SSR के घटकों को फिर से उपयोग कर सकते हैं, जबकि कुशल SSR भी है जो इसके सभी डेटा को लाने में सक्षम है ( getInitialProps माध्यम से) कभी भी रिएक्टर रेंडरर से बात करने से पहले।

मुझे ऐसा लगता है जैसे पेड़ पर चलने के प्रदर्शन की सजा खत्म हो गई है। आज कई प्रोडक्शन एप्लिकेशन जैसे कि अपोलो के साथ कर रहे हैं और यह ठीक प्रतीत होता है।

यदि आप वास्तव में बहुत अधिक काम करने के सर्वर को राहत देना चाहते हैं, तो इसके अलावा आप अपनी प्रतिक्रियाओं को कैश भी कर सकते हैं।

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

आप निश्चित रूप से अपनी प्रतिक्रियाओं को कैश कर सकते हैं, लेकिन यह बहुत सारे वैयक्तिकरण / लॉगिन विकल्पों को समाप्त कर देता है (क्योंकि यह एक व्यापार बंद है कि आप अपने हिट-रेट को कैसे ड्राइव करना चाहते हैं या क्लाइंट को आंशिक पेज रेंडर करना चाहते हैं)। यदि आप अपने पूरे ऐप को सीडीएन कैश कर सकते हैं, तो आप सीआरए और react-snapshot का उपयोग करके बेहतर हो सकते हैं और सर्वर से पूरी तरह से बच सकते हैं। जरूरी नहीं कि यह सवाल हो कि आपका सर्वर कितना काम कर रहा है, बल्कि एक अनुरोध का जवाब देने में कितना समय लगता है।

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

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

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

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

Naive question: क्या आप केवल क्लाइंट पर चल रहे कोड को एक बार शीर्ष स्तर लिंक और लाने / प्रीचेट / कैश कर सकते हैं। यदि आप नहीं जानते कि क्लाइंट कहां नेविगेट करेगा, तो क्या यह सर्वर पर DOM ट्री को पीछे करने के लिए समझ में आता है?

सक्रिय कार्य परिदृश्य: जब क्लाइंट एक URL का अनुरोध करता है तो बस शीर्ष स्तर लिंक और डिफ़ॉल्ट सक्रिय लिंक सामग्री और ajax / सब कुछ अनुरोध पर प्रस्तुत करें (या पृष्ठ लोड होने के बाद एक बार पृष्ठभूमि में प्रीफ़ेक करें) ... बाकी सभी में सभी निचले स्तर शामिल हैं मार्गों ... कुल्ला और दोहराना ...?

@laurencefass लेकिन यहां तक ​​कि शीर्ष स्तर के लिंक कोड में हैं और सही खोजे जाने हैं? या क्या आप प्रतिक्रिया-राउटर के साथ फ़ाइल-सिस्टम रूटिंग का उपयोग करने का मतलब है ताकि शीर्ष स्तर के लिंक खोजे जा सकें?

@ avin-kavish Im कार्यान्वयन पर विवरण का जवाब देने के लिए सबसे अच्छा व्यक्ति नहीं है, लेकिन ग्राहक को केवल प्रारंभिक स्क्रीन सामग्री प्रस्तुत करने की आवश्यकता है: शीर्ष स्तर लिंक + डिफ़ॉल्ट सामग्री। मुझे लगता है कि पहले लोड पर कुछ और बेमानी है। तो सर्वर पर डोम क्यों चलते हैं?

Next.js के साथ मुख्य मुद्दा राउटर नहीं है, यह getInitialProps , getServerProps या getStaticProps साथ डेटा लाने वाला पैटर्न है। क्यों ? क्योंकि यह घटक के लिए डेटा-अलगाव को तोड़ देता है जिसे इसकी आवश्यकता होती है। उदाहरण के लिए, आप मेनू के लिए डेटा प्राप्त करना चाहते हैं, आप इसे कहां से लाएंगे? मुझे नहीं पता। pages जैसे शीर्ष घटकों को इसके बारे में कुछ भी पता नहीं होना चाहिए, है ना?

Next.js के साथ मुख्य मुद्दा राउटर नहीं है, यह getInitialProps , getServerProps या getStaticProps साथ डेटा लाने वाला पैटर्न है। क्यों ? क्योंकि यह घटक के लिए डेटा-अलगाव को तोड़ देता है जिसे इसकी आवश्यकता होती है। उदाहरण के लिए, आप मेनू के लिए डेटा प्राप्त करना चाहते हैं, आप इसे कहां से लाएंगे? मुझे नहीं पता। pages जैसे शीर्ष घटकों को इसके बारे में कुछ भी पता नहीं होना चाहिए, है ना?

क्या आप कृपया विस्तार से बताएंगे। और वैकल्पिक समाधान क्या है?

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

यहाँ मेरे कोड का नमूना है जो मैं स्पष्टता के लिए अपने ऐप का उपयोग कर रहा हूं:

const query = `
{
  result:users(
    where:{
      _and:[{
        active:{
          _eq:true
        }
      }, {
        is_exam_manager:{
          _eq:true
        }
      }]
    },
    order_by:{
      created_at:desc_nulls_last
    }
  ){
    id
    key:id
    user_code
    first_name
    last_name
    password
    active
  }
}
`
const Main = (props: any) => {
  const {
    data: { result }
  } = props
  return (
    <div>
      <Add title={'Add user'} role={'exam_manager'} />
      <Table
        columns={columns}
        dataSource={result}
        bordered={true}
        size={'small'}
      />
    </div>
  )
}
const MainWithData = graphql(query)(Main)
export default MainWithData

जैसा कि आप देखते हैं, आपके पास स्वयं के डेटा के साथ एक घटक है। आप इसे अपनी इच्छानुसार कहीं भी रख सकते हैं।

बेशक, आप बिना किसी समस्या के Next.js पैटर्न का उपयोग कर सकते हैं, लेकिन मेरे मामले में, मैं बाद में आसान रखरखाव और रीफैक्टरिंग के लिए डेटा और घटक के लिए अलगाव पसंद करता हूं।

मेरे ऐप्स में, प्रत्येक घटक को अपना डेटा उसी स्थान पर, उसी फ़ाइल में, जिसे वह ग्राफ़िकल या बाकी है, ठीक घोषित करने की आवश्यकता होगी।
शीर्ष पृष्ठ घटक केवल बाल घटकों की रचना के लिए है, और डेटा प्राप्त करना इसका काम नहीं है। बाल घटक को स्वयं का डेटा प्राप्त करना चाहिए, न कि उसके माता-पिता से।

मैं उसी तरह इसका इस्तेमाल करता हूं।
तो आप SSR का उपयोग नहीं कर रहे हैं ...
फिर कैसे लोग वास्तव में Next.js के साथ SSR ला रहे हैं?

@linshine को हमें शीर्ष पृष्ठ स्तर पर जो भी आवश्यक है उसे डाउनलोड करना होगा।

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

यहाँ मेरे कोड का नमूना है जो मैं स्पष्टता के लिए अपने ऐप का उपयोग कर रहा हूं:

...

जैसा कि आप देखते हैं, आपके पास स्वयं के डेटा के साथ एक घटक है। आप इसे अपनी इच्छानुसार कहीं भी रख सकते हैं।

बेशक, आप बिना किसी समस्या के Next.js पैटर्न का उपयोग कर सकते हैं, लेकिन मेरे मामले में, मैं बाद में आसान रखरखाव और रीफैक्टरिंग के लिए डेटा और घटक के लिए अलगाव पसंद करता हूं।

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

हमारे पास एक रिले-नेक्स्ट ऐप है और यह पैटर्न पूरी तरह से काम करता है, डेटा-एनकैप्सुलेशन और पुन: प्रयोज्य संरचना के साथ, और हम आसानी से getInitialProps लाभ उठाते हैं।

@merrywhether much harder in REST बारे में उल्लेख नहीं करने के लिए, आपके दृष्टिकोण में एक समस्या है कि, आप तय नहीं कर सकते हैं कि कौन सा fragments SSG / SSR होगा या CSR होगा।
मेरे दृष्टिकोण में, { noSSR: true/false} साथ उस घटक को आयात करना जितना आसान है।

मैं एक विशिष्ट विशिष्ट पुस्तकालय के लिए लॉक-इन ढूंढता हूं जो किसी भी प्रमुख मार्ग लाइब्रेरी के साथ अंतर्निहित कार्यान्वयन को साझा नहीं करता है।

मैंने हाल ही में Next.js की समीक्षा करने के लिए मूल्यांकन किया था कि क्या इसका उपयोग हमारे वर्तमान ग्राहक के लिए बनाए जा रहे कई अग्रिम अनुप्रयोगों के बीच साझा किए गए सामान्य कोर के लिए आधार के रूप में किया जाना चाहिए। जबकि Next.js में क्षमता है; यह राउटर उन प्रमुख कारणों में से एक है, जिन्हें मैंने Next.js को खारिज कर दिया और इसके बजाय CRA को इन अनुप्रयोगों के लिए आधार के रूप में रखा।

मैं SSR के लिए आधार के रूप में react-router / @reach/router के घटक आधारित शीर्ष-स्तरीय API का उपयोग करने की कठिनाई को समझता हूं। लेकिन यह अंतर्निहित कार्यान्वयन के पूरी तरह से कस्टम होने का एक अच्छा कारण नहीं है। गैट्सबी के एसएसजी में नेक्स्ट.जेएस और एक अर्ध-समान फ़ाइल आधारित रूटिंग संरचना के समान चिंताएं हैं; लेकिन मेरी समझ में गैट्सबी ने पहिया को फिर से मजबूत करने या एक लिंक एपीआई को उजागर करने के बजाय अपने रूटिंग कार्यान्वयन को शक्ति देने के लिए हुड के नीचे @reach/router उपयोग किया है जो अन्य पुस्तकालयों द्वारा उपयोग किए गए लिंक एपीआई के साथ असंगत है।

@ डेंटमैन मैं पूछ सकता हूं कि आपने Next.js विकल्प के लिए क्या चुना। मान लिया जाए कि आपको सर्वर साइड रेंडरिंग की आवश्यकता है .... मैं कोशिश कर रहा हूं। बाद में शायद यह कुछ प्रेरणा / विचार प्रदान कर सकता है कि Next.js में कैसे लागू किया जाए यदि zeit द्वारा समर्थित नहीं किया जा रहा है।

@ डेंटमैन मैं पूछ सकता हूं कि आपने Next.js विकल्प के लिए क्या चुना। मान लिया जाए कि आपको सर्वर साइड रेंडरिंग की आवश्यकता है .... मैं कोशिश कर रहा हूं। बाद में शायद यह कुछ प्रेरणा / विचार प्रदान कर सकता है कि Next.js में कैसे लागू किया जाए यदि zeit द्वारा समर्थित नहीं किया जा रहा है।

क्षमा करें, मेरे पास आपके लिए उपयोगी उत्तर नहीं है। SSR एक कठिन आवश्यकता नहीं थी इसलिए हम सिर्फ CRA का उपयोग करते रहे, जिसे प्रोटोटाइप के साथ बनाया गया था।

मैंने सोचा कि Next.js ने एक सार्वभौमिक ढांचे के रूप में वादा किया था क्योंकि यह हाल ही में SSR / SSG / ग्राहक-केवल पृष्ठों के मिश्रण की क्षमता प्राप्त कर चुका है और यह एक आइसोमोर्फिक ऐप के रूप में या एक स्थिर / PWA ऐप के रूप में चल सकता है। वेबपैक अनुकूलन लुभावना था क्योंकि सीआरए वैश्वीकरण-संकलक का उपयोग करके कठिन बना रहा है। Next.js सर्वर एक तटस्थ / सकारात्मक था क्योंकि हमें एक ग्राफ सर्वर / REST ब्रिज के लिए एपीआई सर्वर की आवश्यकता थी। और SSR / SSG का विकल्प एक सकारात्मक था क्योंकि मैं कोर का निर्माण कर रहा हूं एक आधा दर्जन अनुप्रयोग आधारित होंगे और यह असंभव नहीं है कि यह भविष्य में उपयोगी हो सकता है। हालाँकि, मेरे पास कुछ मुद्दे भी थे। Next.js के SSR के काम करने के तरीके और ये सकारात्मक राउटर के कारण होने वाली परेशानी के लायक नहीं थे।

@dantman

मैं एक विशिष्ट विशिष्ट पुस्तकालय के लिए लॉक-इन ढूंढता हूं जो किसी भी प्रमुख मार्ग लाइब्रेरी के साथ अंतर्निहित कार्यान्वयन को साझा नहीं करता है।

यह एपीआई के साथ एक खुला स्रोत घटक को अर्हता प्राप्त करने के लिए काफी अजीब है जो 3 साल में इसकी महान स्थिरता और "उत्पाद / बाजार फिट" के कारण "लॉक-इन" के रूप में परिवर्तित नहीं हुआ है।

Next.js सफल रहा है और अपने राउटर के कारण ऐसा विकास दिखाता है जो

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

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

जब मैं कहता हूं कि राउटर की वजह से नेक्स्ट सफल हुआ, ऐसा इसलिए है क्योंकि इसने दो समस्याओं को खत्म कर दिया है:
1 to राउटर चुनने का विचार । इसे हटाने से हम एक उत्कृष्ट निर्णय प्राप्त कर सकते हैं। सभी समय में Next.js के साथ इसका स्थिर राउटर मौजूद है, राउटर की दुनिया ने सभी प्रकार के एपीआई परिवर्तनों को विभाजित और लॉन्च किया है

2 एक राउटर का सीखने की अवस्था । रूटिंग के बारे में कई कार्यशालाएं और ट्यूटोरियल दिए गए हैं, लेकिन Next.js फ़ाइल-सिस्टम रूटिंग में 2 सेकंड का समय लगता है और आपको अविश्वसनीय चीजें बनाने के लिए प्लेटफ़ॉर्म देता है, और आप उत्पाद विकास में सही कदम रखते हैं

मैं इस अंतिम बिंदु पर जोर देना चाहता हूं। दुनिया की सबसे नई और सबसे तेजी से बढ़ती वेबसाइटों में से एक पर विचार करें, TikTok.com, Next.js. पर बनाया गया है। उस वेबसाइट के पूरे रूटिंग टोपोलॉजी को उस दो सेकंड लर्निंग कर्व के साथ समझाया जा सकता है। https://www.tiktok.com/@sheezus.christ/video/6824007862197439750 pages/[user]/video/[id].js और https://www.tiktok.com/trending pages/trending.js

आपके द्वारा बताए गए कई नेक्स्ट.जेएस इनोवेशन में से कई हाइब्रिड स्टैटिक / एसएसजी / एसएसआर जैसे हैं, जो हमारे राउटर डिजाइन द्वारा भी सक्षम हैं। वास्तव में, राउटर कई अन्य समान अनुकूलन भी सक्षम करेगा जो भविष्य में ग्राहकों को कम जेएस वितरित करने के लिए आ रहे हैं।

हालाँकि, मेरे पास कुछ मुद्दे भी थे। Next.js के SSR के काम करने के तरीके और ये सकारात्मक राउटर के कारण होने वाली परेशानी के लायक नहीं थे।

इनके बारे में सुनकर अच्छा लगेगा। ऊपर दिया गया उदाहरण Next.js हाइब्रिड स्टेटिक / SSR द्वारा संचालित है और हम इसे बोर्ड भर में बहुत सी सफलता देखते हैं!

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

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

जब से मैं इस मुद्दे को बंद कर रहा हूं, मैं यह स्पष्ट करना चाहता हूं कि हम हमेशा रूटिंग क्षमताओं पर टिप्पणियों, फीचर अनुरोधों और बग रिपोर्ट के लिए खुले हैं।

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

@ क्रैकग आप दो प्रॉप्स के पीछे का कारण बता सकते हैं, href और as एक लिंक? as प्रोप के मूल्य के आधार पर यह इच्छित पृष्ठ का अनुमान क्यों नहीं लगा सकता?

उदाहरण के लिए यदि मेरे पास /blog/:slug मार्ग है, तो मैं बस /blog/hello-world लिए http अनुरोध भेज सकता हूं और राउटर से इसे रूट करने की अपेक्षा कर सकता हूं। मुझे सर्वर पर /blog/:slug और blog/hello-world भेजने की आवश्यकता नहीं है।

@ avin-kavish यह एक बड़ा सवाल है। URL क्या प्रदर्शित करता है और क्या पेज लोड किया जाना है, इसके बीच एक महत्वपूर्ण अंतर है। तथ्य की बात के रूप में TikTok का उपयोग करता है कि कुछ चीजों को मोडल्स में रेंडर करने के लिए, कि जब आप पृष्ठ को रीफ्रेश करते हैं तो अन्य पेज बन जाते हैं। हालांकि, यहां सुधार का एक बड़ा क्षेत्र यह है कि हमें शायद सांख्यिकीय रूप से लागू करना चाहिए कि आप एक मान्य पृष्ठ को संदर्भित कर रहे हैं जो फ़ाइल-सिस्टम में मौजूद है। हम इस पर एक चर्चा बनाकर आपको फॉलो करेंगे और आपको टैग करेंगे!

मुझे लगता है कि इसके लिए एक मुद्दा पहले से ही मौजूद है https://github.com/zeit/next.js/issues/8207

यदि कोई व्यक्ति इस मुद्दे को "नेस्टेड रूट्स" फीचर जैसे रिएक्टर-राउटर के लिए देखता है, जो मेरे जैसे सब कुछ फिर से प्रस्तुत किए बिना नए पृष्ठों पर नेविगेट करने की अनुमति देता है, तो वास्तव में एक समर्पित मुद्दा है जिसे आप देख सकते हैं और वोट कर सकते हैं। मुझे अभी उस बारे में पता चला है: https://github.com/zeit/next.js/issues/8193

@rauchg

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

मुझे लगता है कि गैट्सबी का दृष्टिकोण स्वीकार्य है। उनके पास एक एसएसजी सक्षम फ़ाइल + कॉन्फ़िगरेशन आधारित रूटिंग एपीआई है और अपने स्वयं के उन्नत लिंक घटक को निर्यात करते हैं; लेकिन वे अंतर्निहित कार्यान्वयन को लागू करने के लिए @reach/router का उपयोग करते हैं।

मैं एक विशिष्ट विशिष्ट पुस्तकालय के लिए लॉक-इन ढूंढता हूं जो किसी भी प्रमुख मार्ग लाइब्रेरी के साथ अंतर्निहित कार्यान्वयन को साझा नहीं करता है।

यह एपीआई के साथ एक खुला स्रोत घटक को अर्हता प्राप्त करने के लिए काफी अजीब है जो 3 साल में इसकी महान स्थिरता और "उत्पाद / बाजार फिट" के कारण "लॉक-इन" के रूप में परिवर्तित नहीं हुआ है।

रूटर आंतरिक रूप से Next.js. से बंधा होता है एक कारण के लिए Next.js को अपनाने का मतलब है कि राउटर से बंधा होना। अगर हम Next.js को अपनाते हैं और बाद में पता चलता है कि अगले / राउटर में एक सीमा है जो किसी ऐसी चीज़ के लिए अपंग हो जाता है जिसे हम करने की कोशिश कर रहे हैं तो वहाँ कोई उचित पलायन नहीं है। "लॉक-इन" उसके लिए एक बिल्कुल ठीक वर्णनकर्ता है।

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

हालांकि मैं उलझन में हूं कि आपके मन में कौन सा मानक है, रीच या रिएक्ट राउटर, और किस प्रमुख संस्करण पर

<Link> क्या दिखना चाहिए के वास्तविक तथ्य के संदर्भ में। रीच और रिएक्ट राउटर (आरआर) दोनों बहुत समान एपीआई साझा करते हैं। जैसे <Link to='/about'>About</Link> RR और Reach दोनों में मान्य है (और विस्तार से Gatsby)। जो नेक्स्ट.जेएस के आइडियलसोनिक <Link href='/about'><a>About</a></Link> इतना अधिक चिढ़ाता है।

मेरे विचार से Next.js का उपयोग करना चाहिए। अगर मैं पहले से ही एक दूसरे का उपयोग करने का सुझाव नहीं दे रहा था, तो Next.js पहले से ही उपयोग कर रहे थे, मैं एक विशिष्ट पुस्तकालय से बंधा नहीं हूं। मेरी प्रमुख चिंता यह है कि रूटिंग कार्यान्वयन को लाइब्रेरी के साथ Next.js. के बाहर एक व्यापक समुदाय के साथ साझा किया जाए।

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

मैंने कुछ समय पहले नेक्स्ट किया था लेकिन राउटर पर लचीलेपन की कमी के कारण मुझे Razzle कार्यान्वयन की खोज करने के लिए प्रेरित किया

जैसा कि रिएक्ट राउटर सिर्फ एक पैकेज है, क्या हम इसे आयात नहीं कर सकते हैं और केवल क्लाइंट साइड तक ही सीमित कर सकते हैं, इसलिए यह एसपीए की तरह काम करता है, जहां इसकी जरूरत है और हमें नेस्टेड घटक रूट देते हैं? Isnt React रूटर सिर्फ (संभावित) होने वाले घटकों का एक सेट है जो पृष्ठों में एम्बेडेड है और किसी भी अन्य घटकों की तरह Next.js पृष्ठ रूटर के साथ लोड किया गया है?

मैंने पहले थ्रेड्स में पढ़ा कि आरआर को एकीकृत करने के लिए ज़ीइट की योजना क्या आज भी सच है?

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

मैं इस मुद्दे पर अपना वोट जोड़ रहा हूं।

एक अन्य समर्थक, जिसका उल्लेख नहीं किया गया है, यह है कि आरआर इसकी अधिक परीक्षण योग्य है, (एएफएआईके राउटर परीक्षण के लिए कोई आधिकारिक नेक्स्ट एपीआई नहीं है), इसमें रैपराउंड परीक्षण और कहानियां हैं।

Next.js में बहुत सारी अच्छी सुविधाएँ हैं (स्वचालित वेबपैक, स्टैटिक फाइल्स, और टाइपआरए जैसे CRA लेकिन केवल PWA, API रूट्स से अधिक के लिए; सर्वरलेस सपोर्ट, फास्ट रिफ्रेश और यहां तक ​​कि प्रायोगिक एक्सपो सपोर्ट वेब + नेटिव एप्स के लिए) और एक कोर SSR और SSG के लिए भले ही इसके लिए एपीआई बढ़िया नहीं है। लेकिन जब अंतर्निहित रूटिंग सिस्टम और एसएसआर / एसएसजी कुछ के लिए काम करता है; दूसरों के लिए वे विकास का शौक रखते हैं क्योंकि दोनों एपीआई की सीमाएं उक्त परियोजना के लिए गलत व्यापार की पेशकश करती हैं।

कैसे एक समझौता Next.js में पहले से ही प्लगइन्स हैं। इसके बजाय राउटर को आंतरिक रूप से बदलने के बजाय अगर हमने राउटर और एसएसआर एपीआई (यानी getStaticProps / getServerSideProps रूट फाइल्स में) को Next.js. के कोर से अलग किया। उदाहरण के लिए हम @next/core में बहुत ही मूल कोर भागों को रख सकते हैं और वर्तमान राय वाले राउटर और get*Props API को @next/router स्थानांतरित कर सकते हैं। सादगी और पश्चगामी अनुकूलता के लिए next एक ढांचा हो सकता है जो @next/core पुनः निर्यात करता है और वर्सेल के पसंदीदा राउटर के साथ पूर्व-कॉन्फ़िगर होता है। लेकिन तब समुदाय के लिए अलग-अलग ट्रेड-ऑफ के साथ राउटर और एसएसआर / एसएसजी एपीआई विकसित करना संभव होगा, जो उन परियोजनाओं के लिए बेहतर हैं जो अन्यथा बाथटब के साथ नेक्स्ट.जेएस के अच्छे हिस्सों को बाहर फेंक देंगे।

Next.js कोर क्या प्रदान करने के लिए रूटर प्लगइन की आवश्यकता होगी पर कुछ विचार:

  • अनुरोध {url, body, आदि} को देखते हुए कोर राउटर प्लगइन से इस अनुरोध को एक दस्तावेज (स्ट्रिंग या स्ट्रीमिंग) के लिए प्रस्तुत करने या प्रतिक्रिया (यानी 404 या रीडायरेक्ट) को फेंकने की अपेक्षा करेगा।
  • निर्यात पर कोर राउटर प्लगइन को उन पृष्ठों की एक सूची प्रदान करने की उम्मीद करेगा, जिन्हें प्रदान करने की आवश्यकता है।

@next/router शायद जैसे काम करके एपीआई के माध्यम से समान पैटर्न लागू करेंगे:

  • एक अनुरोध को देखते हुए, रूट फ़ाइल की पहचान करना और सामान्य रूप से प्रस्तुत करना
  • एसएसआर एपीआई को कॉल करने के लिए और वर्तमान में इसकी आवश्यकता के मार्ग को प्रस्तुत करने के लिए यह जानने के लिए कि वर्तमान में जो कुछ भी है, उसके समान कुछ करने वाले ग्राहक पर (संभवतः एपीआई आधारित एसएसआर एपीआई को एक सामान्य दिखने वाले एपीआई मार्ग को स्थानांतरित करना)
  • स्थैतिक पृष्ठों की सूची प्रदान करने के लिए पेज फ़ाइल ट्री और getStaticPaths का उपयोग करके निर्यात करें

मैं शायद अपने आप को एक राउटर प्लगइन के साथ @apollo/react-ssr react-ssr-prepass react@experimental react-ssr-prepass @apollo/react-ssr और सहायता से चलाकर देख सकता था। जो एसएसआर-ओनली रूट्स को आइसोमॉर्फिक एसएसआर मार्गों के लिए क्षमा करता है और get*Props शैली एपीआई को प्रतिबंधित किए बिना SSR / SSG को लागू करता है।

मुझे एहसास हुआ कि नेस्टेड रूटिंग + एसएसजी वर्तमान एपीआई को तोड़ने के बिना प्राप्त करने योग्य है। इस समय हमारे पास getStaticPaths , हम इसका उपयोग पूर्व-प्रतिपादन के लिए नेस्टेड मार्गों पर संकेत देने के लिए कर सकते हैं। उदाहरण के लिए,

मार्ग को देखते हुए /foo/[...slug] ,

function FooPage() {

  return (
      <Switch>
          <Route path="/foo/bar">
              <SomeResource />
              <Route path={`${parenthPath}/baz`} component={SomeSubResource} />
          </Route>
          .... more routes
      </Switch>
  )
}

के साथ पूर्व-प्रदान किया जा सकता है,

export async function getStaticPaths() {

  return {
    paths: [
      { slug: [ 'bar' ] },
      { slug: [ 'bar', 'baz' ] },
    ],
  }
}

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

@ avin-kavish मुख्य मुद्दा यह काम करने के लिए नहीं है, लेकिन इसे अनुकूलित करने के लिए है: Next.js डिफ़ॉल्ट पर प्रत्येक पृष्ठ का अपना बंडल है और गति के लिए अनुकूलित है।

यदि आपने एक ही पृष्ठ में बहुत सारी सामग्री / उप-सामग्री जोड़ना शुरू कर दिया है, तो आप अंत में एक बहुत बड़ी बंडल के साथ समाप्त हो सकते हैं (जो कि प्रति से "भयानक" नहीं है, लेकिन आपको बस पता होना चाहिए व्यापार गत)। आप next/dynamic सोचा :) के साथ कुछ मैनुअल अनुकूलन करने में सक्षम हो सकते हैं :)

@ आउच एकमात्र आयाम यह नहीं है कि अगला राउटर अच्छा है या बुरा। एक और बहुत ही महत्वपूर्ण चीज़ है। अगली और जे.जे. और सामुदायिक सहायता से माइग्रेशन, और https://github.com/vercel/next.js/issues/1632#issuecomment -633310614 इसे अच्छी तरह से रखें। Next.js इस तरह का एक अच्छा समाधान है कि बहुत सारे बॉयलरप्लेट को उच्च-गुणवत्ता वाले एसएसआर ऐप की जरूरत है, और जैसे कि यह कई वेब ऐप के लिए बहुत ही आमंत्रित माइग्रेशन लक्ष्य है। अभी समस्या यह है कि इसे अगले रूट में माइग्रेट करने के लिए पूरी तरह से राउटिंग को फिर से लिखने की आवश्यकता होगी, और यदि आवश्यकता होती है तो इसमें से बाहर।

@Dantman द्वारा पहले सुझाई गई

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

प्रतिक्रिया-राउटर उपयोगकर्ताओं को प्रतिक्रिया-लोड करने योग्य का उपयोग करने के लिए उपयोग किया जाता है क्योंकि यह आरआर प्रतिनिधि को पूरी तरह से अंतिम-उपयोगकर्ताओं के लिए जिम्मेदारी सौंपता है, लेकिन अगला इसे आसान नहीं है जो इसे अमूर्त और स्वचालित करने का प्रयास करता है। प्रस्तावित प्

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

लंबी कहानी छोटी / नीचे का एक अच्छा सारांश: "एक आकार सभी समाधान फिट बैठता है" जैसी कोई चीज नहीं है। हर चीज में ट्रेड-ऑफ है। रास्ते के हर "लाभ" Next.js वर्तमान में चीजों को नुकसान के साथ आता है। क्या फायदे / नुकसान सबसे महत्वपूर्ण हैं कुछ ऐसा है जो प्रत्येक परियोजना के लिए अलग है। इसलिए, एक प्लगेबल राउटर / एसएसजी / एसएसआर आर्किटेक्चर के लिए सिफारिश। अलग-अलग प्रोजेक्ट्स को अलग-अलग चीजों की जरूरत होती है और अभी Next.js केवल उन प्रोजेक्ट्स के लिए काम करता है, जिनकी ट्रेड-ऑफ्स पर प्राथमिकता नेक्स्टज में जिस तरह से चीजों को हार्डकोड किया जाता है, उसके साथ एलाइन करता है।

प्रतिक्रिया-राउटर (और किसी भी नेस्टेड रूटिंग समाधान) के साथ समस्या यह है कि यह स्थैतिक विश्लेषण को बहुत कठिन बना देता है क्योंकि किसी भी विशिष्ट URL के लिए प्रासंगिक कोड पथ कोड के बिना ही चल (या अनुकरण) उपलब्ध नहीं हैं।

ईमानदारी से यह केवल तभी मायने रखता है जब आप एसएसजी का उपयोग कर रहे हों और गैर-गतिशील मार्गों का एक समूह हो। यदि आपके सभी मार्ग SSG या केवल क्लाइंट हैं, तो यह उपयोगी नहीं है। और यदि आपके अधिकांश मार्ग गतिशील हैं, तो आपको getStaticPaths वैसे भी उन्हें स्पष्ट रूप से घोषित करना होगा। जो काम का एक ही राशि के रूप में एक काल्पनिक Next.js प्लगइन में मार्गों को स्पष्ट रूप से परिभाषित करता है जो बिना संशोधन के कच्चे प्रतिक्रिया-राउटर का उपयोग करता है और आपको स्थैतिक मार्गों को स्पष्ट रूप से परिभाषित करने के लिए कहता है।

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

यह भी मानता है कि हर कोई जो next/router चाहता है, वह प्रतिक्रिया-राउटर के JSX फॉर्म का उपयोग करना चाहता है। यह next/router विकल्प का एकमात्र प्रकार नहीं है।

एक अन्य प्रकार का राउटर Gatsby.js शैली होगा। जहां एक परियोजना अभी भी फाइलसिस्टम आधारित पेज संरचना का उपयोग करती है, लेकिन इंटर्ल्स को एक अन्य रूटिंग लाइब्रेरी जैसे रिएक्शन-राउटर के साथ कार्यान्वित किया जाता है (गैट्सबी आंतरिक रूप से @reach/router का उपयोग करता है)। इस तरह के राउटर प्लगइन आपको समान स्थैतिक-विश्लेषण लाभ देगा। लेकिन यह आपको यह भी बताएगा कि वैकल्पिक राउटर ने नेस्टेड रूटिंग से संबंधित कोई लाभ नहीं है। जैसे रूट एपीआई के लिए संभावित वरीयताओं को समझना, पहुंच की बेहतर हैंडलिंग, उस राउटर के इकोसिस्टम में बेहतर एकीकरण।

और निश्चित रूप से प्रतिक्रिया-राउटर पारिस्थितिकी तंत्र के भीतर भी जेएसएक्स फॉर्म प्रतिक्रिया-राउटर का उपयोग करने का एकमात्र तरीका नहीं है। प्रतिक्रिया-राउटर-कॉन्फ़िगरेशन भी है । जिस पर स्थैतिक विश्लेषण करना आसान है और नेस्टेड रूटिंग का भी समर्थन करता है।

प्रतिक्रिया-राउटर उपयोगकर्ताओं को प्रतिक्रिया-लोड करने योग्य का उपयोग करने के लिए उपयोग किया जाता है क्योंकि यह आरआर प्रतिनिधि को पूरी तरह से अंतिम-उपयोगकर्ताओं के लिए जिम्मेदारी सौंपता है, लेकिन अगला इसे आसान नहीं है जो इसे अमूर्त और स्वचालित करने का प्रयास करता है।

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

यह एक साइड नोट की अधिक है, लेकिन मैं वास्तव में एक बेबल / वेबपैक प्लगइन की क्षमता के बारे में उत्सुक हूं जो मार्गों के लिए यह स्वचालित रूप से करेगा।

इसके अलावा प्रतिक्रिया-लोड करने योग्य एक प्रभावी रूप से दोषपूर्ण पुस्तकालय है (प्रकाशित होने के बाद 2 साल, बग रिपोर्ट स्वीकार नहीं करना)। व्यक्तिगत रूप से मैं बल्कि मैन्युअल रूप से @loadable/components साथ कोड विभाजन करना चाहता हूं जो कि प्रतिक्रिया-लोड करने योग्य के आंतरिक कांटे के आधार पर Next.js में स्वचालित रूप से निर्मित कुछ का उपयोग करें।

प्रस्तावित प्

हाँ। यह आमतौर पर एक प्लगइन सिस्टम कैसे काम करेगा। ईमानदारी से तथ्य यह है कि प्लगइन द्वारा इस तरह की जानकारी प्रदान की जा सकती है एक फायदा है, समस्या नहीं है। एक प्लगइन में होने का मतलब है कि जिस तरह से Next.js को इकट्ठा करना चाहिए यह जानकारी कुछ प्रकार की परियोजनाओं की जरूरतों के लिए उपयुक्त नहीं है, इसे उन परियोजनाओं के साथ फिट होने वाले एक के साथ बदला जा सकता है। लेकिन फोर्क की आवश्यकता के बिना और ऐसा करने के लिए Next.js के सभी को फिर से लिखना।

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

यह वास्तव में एक प्लग-इन राउटर सिस्टम पर काम करने के लिए वास्तव में एक बहुत अच्छा तर्क हो सकता है। अभी क्योंकि राउटिंग और SSR के सभी सामान नेक्स्ट में हार्डकोडेड हैं। ऐसे में नेक्स्ट.जेएस के भीतर किसी भी प्रकार के राउटिंग सिस्टम में एक्सपेरिमेंट आसानी से करना संभव नहीं है। सस्पेंस Next.js की रूटिंग और अन्य रूटिंग लाइब्रेरी को कैसे प्रभावित करता है? ऐसा कुछ नहीं, जिसके साथ आप प्रयोग कर सकते हैं (कम से कम Next.js के SSR और बंडलिंग के संबंध में) Next.js. की चिटकने और फिर से लिखने के बिना।

राउटर प्लगइन्स इस तरह के प्रयोग करने के लिए एक शानदार जगह होगी। जब तक प्लगइन एपीआई निम्न स्तर का है, तब तक यह केवल next/router प्लगइन को कांटा करने और उस राउटर के एक प्रयोगात्मक @ सस्पेंस + आधारित संस्करण को लिखने की कोशिश करेगा। और क्योंकि यह एक प्लगइन है (Next.js के सभी का एक कांटा नहीं), नए सस्पेंस आधारित राउटर का प्रयोग और परीक्षण करना आसान होगा। यह अब बजाय बाद महत्वपूर्ण है, क्योंकि इस तरह का प्रयोग है क्यों प्रतिक्रिया @ प्रयोगात्मक मौजूद है, असली परियोजनाओं से प्रतिक्रिया इकट्ठा करने के लिए।

@dantman मैं आपके द्वारा कही गई किसी भी बात से असहमत नहीं हूं। यह _is_ सभी ट्रेड-ऑफ के बारे में है। सबसे बड़ा व्यापार यह है कि अगली टीम अपना समय किस पर व्यतीत करती है। अब तक, कम-विन्यास उच्च-प्रदर्शन एसएसआर उनका मुख्य फोकस रहा है। मैं समझता हूं कि यह सभी उपयोगकर्ताओं के लिए जरूरी नहीं है, लेकिन यह वह कोण है जिसे शुरू में इस्तेमाल किया गया था (यही कारण है कि हम उन्हें काम पर चुनते हैं)। वे हाल ही में SSG में अधिक खोद चुके हैं, Gatsby और Jamstack की लोकप्रियता के कारण प्रतीत होता है, लेकिन वे अभी भी SSR imo के लिए सर्वश्रेष्ठ हैं।

ईमानदारी से कि अगर आप एसएसजी का उपयोग कर रहे हैं और गैर-गतिशील मार्गों का एक समूह है तो ही मायने रखता है

मुझे यकीन नहीं है कि आप इसका क्या मतलब है, क्योंकि एसएसजी बनाम एसएसआर वास्तव में पहले पृष्ठ ("महत्वपूर्ण पथ" जेएस) के लिए सबसे छोटा संभव जेएस पेलोड देने की कोशिश करने के लिए कोई फर्क नहीं पड़ता है, न ही गतिशील मार्ग। महत्वपूर्ण पथ एसेट्स को कम से कम _is_ आमतौर पर SSR ऐप्स के लिए बहुत महत्वपूर्ण है (इस प्रकार सभी प्रयास) तो इसकी सराहना की जाती है। और ईमानदारी से, अगर आप सभी लॉग-इन कर रहे हैं तो सीएसआर-ओनली ऐप्स हैं, फिर नेक्स्ट _does_ में CRA (SSR CSR जितना सुविधाजनक कभी नहीं होगा) की तुलना में बहुत अधिक डाउनसाइड हैं। ऐसा लगता है कि आप उन ऐप्स को छूट दे रहे हैं जो वास्तव में रनटाइम एसएसआर कर रहे हैं (विशेष रूप से पूर्ण जीत के लिए लॉगिन / निजीकरण के सर्वर-साइड हैंडलिंग के साथ)। सब कुछ एसएसजी बनाम सीएसआर डिक्टोटॉमी में फिट नहीं होता है।

हममें से कुछ खुद को कोड-विभाजन करने से ठीक कर रहे हैं

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

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

ईमानदारी से कि अगर आप एसएसजी का उपयोग कर रहे हैं और गैर-गतिशील मार्गों का एक समूह है तो ही मायने रखता है

मुझे यकीन नहीं है कि आप इसका क्या मतलब है, क्योंकि एसएसजी बनाम एसएसआर वास्तव में पहले पृष्ठ ("महत्वपूर्ण पथ" जेएस) के लिए सबसे छोटा संभव जेएस पेलोड देने की कोशिश करने के लिए कोई फर्क नहीं पड़ता है, न ही गतिशील मार्ग।

हम शायद अलग-अलग कारणों के बारे में सोच रहे हैं कि क्यों मार्गों के अस्तित्व के लिए सांख्यिकीय रूप से विश्लेषण करने की क्षमता आवश्यक है। यह मानते हुए कि हम दोनों "स्थैतिक विश्लेषण" के बारे में बात कर रहे हैं, "बस कोड को पढ़ने के समय के निर्माण में मार्गों की सूची (जैसे ['/about', '/', '/profile'] ) की पहचान करने की क्षमता"।

ऐसा लगता है कि आप किसी प्रकार के जेएस बंडल अनुकूलन के बारे में बात कर रहे हैं? जो मुझे दस्तावेज़ीकरण में कोई जानकारी नहीं मिली है, इसलिए मुझे इस बात की जानकारी नहीं है कि आप जिस स्थैतिक मार्ग विश्लेषण के बारे में सोच रहे हैं, उसके आधार पर किस प्रकार का अनुकूलन है।

मेरा विचार था कि मार्गों का यह स्थैतिक विश्लेषण मुख्य रूप से एसएसजी के लिए उपयोगी था। जब आप अपनी साइट का निर्माण करते हैं तब pages/about.js फ़ाइल मौजूद होती है। अगला जानता है कि /about मार्ग मौजूद है और इसे इस मार्ग के लिए html को पूर्व-प्रस्तुत करने की आवश्यकता है, भले ही आपने इसे स्पष्ट रूप से कभी नहीं बताया हो रेंडर करने के लिए /about रूट है।

SSR को पहले से निर्मित html की आवश्यकता नहीं है क्योंकि यह केवल तभी करता है जब कोई अनुरोध आता है (जिस बिंदु पर यह कोड चलाता है और रेंडर करने के लिए एक रास्ता है)। क्लाइंट-रेंडर किए गए पृष्ठों में पहले से HTML नहीं है। और अगर आपका SSG पेज डायनामिक है तो आपको सभी रास्तों को वैसे भी घोषित करने की आवश्यकता है। इसलिए मेरे विचार

और ईमानदारी से, अगर आप सभी लॉग-इन कर रहे हैं तो सीएसआर-ओनली ऐप्स हैं, फिर नेक्स्ट _does_ में CRA (SSR CSR जितना सुविधाजनक कभी नहीं होगा) की तुलना में बहुत अधिक डाउनसाइड हैं।

CSR ऐप्स के संबंध में Next.js में आप क्या सोच रहे हैं? उपरोक्त राउटर मुद्दों के अलावा।

मेरी समझ के लिए Next.js SSR / SSG / CSR मार्गों के पूर्ण सरगम ​​का समर्थन करता है। तो यह माना जाता है कि यह अभी भी लॉगिन-दीवारों वाले CSR- केवल ऐप्स को लिखने के लिए उपयुक्त है।

व्यक्तिगत रूप से मेरा दृष्टिकोण निश्चित रूप से किसी बड़े पैमाने पर सीएसआर ऐप लिखने वाले किसी व्यक्ति से है, कभी-कभी एसएसआर और एसएसजी की जरूरत के साथ, मेरी सभी परियोजनाओं के लिए एक ही मजबूत टूलकिट चाहते हैं, एसएसआर / एसएसजी / सीएसआर के मिश्रण का कोई मतलब नहीं है।

मेरे अनुभव से CRA को CSR- केवल ऐप्स के भीतर भी काफी नुकसान हुआ है जो Next.js के CSR- पेज को उपयोगी बना सकते हैं। बेदखल किए बिना वेबपैक कॉन्फिग कस्टमाइजेशन एक बड़ा है। जब मुझे एक ऐप में i18n जोड़ रहा था, तो जब मैं बस ग्लोबलाइज़-कंपाइलर वेबपैक प्लगइन का उपयोग नहीं कर सका, तो मुझे बहुत दर्द हुआ। SSR / SSG के विशिष्ट पृष्ठों के लिए ऑप्ट-इन करने की क्षमता भले ही अधिकांश पृष्ठ CSR का हो, एक लाभ भी है (जैसे कि आपके ९९.९% पृष्ठ CSR हैं और एक लॉगिन पृष्ठ के पीछे; लेकिन आपके पास लैंडिंग पृष्ठ और शायद शर्तें / संपर्क हैं वे पृष्ठ जो आप SSG या SSR चाहते हैं)। CRA की तरह सामान के साथ उन चीजों में से कोई भी नहीं कर सकते।

हममें से कुछ खुद को कोड-विभाजन करने से ठीक कर रहे हैं

हम में से कुछ काफी सक्षम वेबपैक, रिएक्शन-डोम / सर्वर आदि स्वयं भी हैं। नेक्स्ट का लक्ष्य अब तक CRA की तरह ही इस तरह के इजेक्शन रेयर और रेयर बनाने के लिए लग रहा है

ईमानदारी से, मैन्युअल रूप से रूट आधारित कोड-विभाजन करना (यह सुनिश्चित करना कि आप अपने रूट घटकों को React.lazy या एक प्रत्यक्ष आयात के बजाय एक वैकल्पिक पुस्तकालय के माध्यम से संशोधित करने के लिए संशोधित करते हैं) एक कस्टम वेबपैक कॉन्फ़िगरेशन या लेखन को मैन्युअल रूप से प्रबंधित करने से बहुत दूर है। react-dom/server साथ आपके अपने SSR हैंडलर्स।

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

जब हमेशा नेक्स्टJS के साथ react-router इंटीग्रेट करने का तरीका खोजा जाता है, तो मैं हमेशा इस मुद्दे पर उतरता हूं कि कस्टम सर्वर बनाने की आवश्यकता नहीं है, इसलिए मैंने इसे स्वयं आजमाने का फैसला किया।

react-router v6 (बीटा) के साथ, एक कस्टम _app बनाएँ

// _app.js || _app.tsx
import * as React from 'react'
import App from 'next/app'
import NextRouter from 'next/router'

export default class CustomApp extends App {
    render() {
        const { Component, pageProps } = this.props

        if (process.browser) {
            const { Router } = require('react-router-dom')
            const { createMemoryHistory } = require('history')
            const history = createMemoryHistory({
                initialEntries: [this.props.router.asPath],
            })

            history.listen(function ({ action, location }) {
                const url = {
                    hash: location.hash,
                    pathname: location.pathname,
                    search: location.search,
                }
                switch (action) {
                    case 'PUSH':
                        return NextRouter.push(url)
                    case 'REPLACE':
                        return NextRouter.replace(url)
                    default:
                        return void 0
                }
            })

            return (
                <Router location={history.location} navigator={history} action={history.action}>
                    <Component {...pageProps} />
                </Router>
            )
        } else {
            const { StaticRouter } = require('react-router-dom/server')
            return (
                <StaticRouter location={this.props.router.asPath}>
                    <Component {...pageProps} />
                </StaticRouter>
            )
        }
    }
}

क्यों

NextJS में (जैसे: /foo/[[...bar]].js ) _optional सभी मार्गों को प्रबंधित करना आसान नहीं है, इसलिए मैं इस तरह के पृष्ठों के लिए react-router का उपयोग करने में सक्षम होने का एक तरीका खोज रहा हूं। हो सकता है कि अन्य लोगों के पास अलग-अलग कारण हों, लेकिन यह मेरी मुख्य चिंता है और react-router एक अच्छा एपीआई प्रदान करता है, विशेष रूप से v6 में जो वर्तमान में बीटा में है।

यह काम किस प्रकार करता है

यह सिर्फ एक कस्टम बनाता है MemoryRouter के बजाय एक BrowserRouter तो हम नहीं NextJS रूटर और NextJS रूटर होने से ब्राउज़र इतिहास अप गड़बड़ है। यह PUSH और REPLACE लिए मेमोरी हिस्ट्री में बदलाव को सुनता है ताकि आप नेविगेट करने के लिए react-router हुक या Link का उपयोग कर सकें लेकिन हुड के नीचे, यह होगा NextJS राउटर के तरीकों को .push और .replace कॉल करना।

NextJS राउटर विधियों को कॉल करना आवश्यक है, अन्यथा मार्ग परिवर्तन वास्तव में NextJS get*Props विधियों को ट्रिगर नहीं करेंगे। दूसरे शब्दों में, यह NextJS Link का उपयोग करके shallow विकल्प के समान काम करेगा। react-router Link का उपयोग करने का नकारात्मक पक्ष यह है कि prefetch । हालाँकि, आप अभी भी NextJS Link उपयोग कर सकते हैं और react-router अभी भी मार्ग परिवर्तन पर प्रतिक्रिया कर सकते हैं।

इसके बारे में अच्छी बात यह है कि अब आप NextJS dynamic और react-router मार्गों का लाभ उठा सकते हैं और इस तरह के काम कर सकते हैं:

// /foo/[[...bar]].js
import * as React from 'react'
import { Route, Routes } from 'react-router-dom'
import dynamic from 'next/dynamic'

const Home = dynamic(() => import('src/views/Home'))
const About = dynamic(() => import('src/views/About'))
const Navigation = dynamic(() => import('src/views/Navigation'))

export default function Root() {
    return (
        <>
            <Navigation />
            <Routes>
                <Route path="/foo/" element={<Home />} />
                <Route path="/foo/about" element={<About />} />
            </Routes>
        </>
    )
}

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

Next.js 9.5+ के साथ रिएक्ट राउटर का उपयोग करना

आपको बस इतना करना Next.js 9.5 या बाद में सही तरीका उपयोग कर रहे हैं इस के साथ है पुनर्लेखनों । _ एक कस्टम सर्वर_ का उपयोग न करें! यहाँ कैसे करें इस पर विस्तृत ट्यूटोरियल है: https://colinhacks.com/essays/building-a-spa-with-nextjs

मूल विचार:

  1. एक कस्टम ऐप बनाएं ( /pages/_app.tsx )

  2. null लौटाएं यदि typeof window === "undefined" । प्रतिक्रिया-राउटर को SSR चरण के दौरान त्रुटियों को फेंकने से रोकने के लिए यह आवश्यक है!

// pages/_app.tsx

import { AppProps } from 'next/app';

function App({ Component, pageProps }: AppProps) {
  return (
    <div suppressHydrationWarning>
      {typeof window === 'undefined' ? null : <Component {...pageProps} />}
    </div>
  );
}

export default App;

suppressHydrationWarning विशेषता चेतावनियों को रोकने के लिए है जब सर्वर द्वारा प्रदान की गई सामग्री क्लाइंट-प्रदान की गई सामग्री से असहमत हो जाती है।

  1. मुखपृष्ठ के सभी मार्गों को फिर से लिखें
// next.config.js

module.exports = {
  async rewrites() {
    return [
      // Rewrite everything else to use `pages/index`
      {
        source: '/:path*',
        destination: '/',
      },
    ];
  },
};

फिर आप सामान्य की तरह रिएक्ट राउटर का उपयोग कर सकते हैं! लिंक किए गए ट्यूटोरियल में बहुत अधिक संदर्भ / स्पष्टीकरण है लेकिन यह आपको आरंभ कर देगा। https://vriad.com/essays/building-a-spa-with-nextjs

@colinhacks अच्छा समाधान यह पुष्टि करता है कि यह काम करता है। हो सकता है कि कुछ सोचने के लिए ऐप को अपने पेज पर ले जाया जा रहा हो, जैसे app.js या path.js या कुछ और। फिर करने के लिए फिर से लिखना

// next.config.js

module.exports = {
  async rewrites() {
    return [
      {
        source: '/app/:path*',
        destination: '/app',
      },
    ];
  },
};

बस कुछ सोचने के लिए, आपका समाधान मुझे मिला सबसे अच्छा है।

क्या यह पृष्ठ उपयोगी था?
0 / 5 - 0 रेटिंग्स