cc @jxnblk

cc @alexindigo @DullReferenceException

आपकी प्रतिक्रिया के लिए अच्छा लगेगा feedback

कोड के साथ खेलने के बाद मुझे महसूस हुआ कि assetPrefix को कई भागों में विभाजित करना बहुत आसान होगा:

module.exports = {
  host: NOW_URL ? `https://${alias}` : 'http://localhost:3000',
  basePath: '/account',
}

हम अभी भी assetPrefix चर को आंतरिक रूप से रख सकते हैं, लेकिन उपयोगकर्ता को अधिक सटीक रूप से परिभाषित करना चाहिए कि उसे क्या चाहिए।

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

एक पक्ष के रूप में यह भी कम कोड परिवर्तन की ओर जाता है।
यदि आप उन दो पीआर की तुलना करते हैं तो यह काफी स्पष्ट है:
https://github.com/panter/next.js/pull/2 (विभाजन)
https://github.com/panter/next.js/pull/1 (दोनों पास)

मेरी राय में, उन्हें अलग होना चाहिए, इसका कारण यह है कि assetPrefix रखने के लिए इसे तोड़ना और अधिक लचीला नहीं है और basePath अलग है।

क्या assetPrefix सही नाम है? दोनों चर वास्तव में एक उपसर्ग अधिकार हैं?

assetPrefix संपत्ति के लिए

इसके काम करने का तरीका इस प्रकार है:

• यदि बंडल को लोड करने के लिए assetPrefix का उपयोग assetPrefix है, तो राउटर को स्पर्श न करें (वर्तमान व्यवहार)
• यदि assetPrefix और basePath उपयोग प्रदान की जाती हैं assetPrefix लोड बंडलों को जोड़ने, basePath रूटर से
• यदि assetPrefix परिभाषित नहीं है और basePath है, तो बंडलों को लोड करने के लिए basePath का उपयोग करें, और रूटर में basePath जोड़ें
• अगर न तो assetPrefix और न ही basePath को परिभाषित किया जाता है तो हम कुछ भी अलग नहीं करते हैं (वर्तमान व्यवहार जब assetPrefix प्रदान नहीं किया जाता है)

cc @alexindigo @DullReferenceException @ 3rd-Eden

क्या आप उक्त प्रस्ताव पर प्रतिक्रिया दे सकते हैं: https://github.com/zeit/next.js/issues/4998#issuecomment -414978297

@tomaswitek यह निश्चित नहीं है कि आपके लिए वर्तमान assetPrefix साथ वास्तव में क्या काम नहीं किया है, यह वह संपत्ति उपसर्ग है जिसका हम उत्पादन में उपयोग कर रहे हैं: "assetPrefix":"https://static.trulia-cdn.com/javascript" और यह अपेक्षा के अनुरूप काम करता है।

और सामान्य तौर पर, हम एक ही डोमेन पर कई ज़ोन (हम उन्हें द्वीप कहते हैं) का उपयोग कर रहे हैं और प्रत्येक द्वीप पर "बेसपासिंग" कभी नहीं किया गया है, क्योंकि यह द्वीपों के बीच अंतर को जटिल करेगा। मुझे थोड़ा और विस्तार से बताएं:

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

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

2. द्वीपों के बीच क्रॉस लिंक - द्वीपों की भावना को एक अलग तैनाती योग्य संस्थाओं के रूप में रखने के लिए विभिन्न द्वीपों के बीच कोई आंतरिक कार्यान्वयन ज्ञान लीक नहीं होना चाहिए।
   इसलिए द्वीपों के लिए एक-दूसरे के पृष्ठों को संदर्भित करने का सबसे अच्छा तरीका है, उनके लिए अन्य द्वीपों के लिए उपलब्ध मार्गों को निर्यात करने के लिए है (अगली दुनिया में _and यह कस्टम <IslandALink> तरह के घटकों की तरह दिखता है) मार्ग_)।
   अब तक यह सभी सीधे आगे है - सभी द्वीप एक ही डोमेन को साझा करने के लिए मानते हैं और उनके पूर्ण पथ ( /path1 , path2 , इत्यादि) का सेट करते हैं। इस तरह दूसरा द्वीप उन रास्तों की सूची को आयात करता है और स्थिर होने के लिए उस पर निर्भर करता है। एक ही समय में यह प्रत्येक द्वीप के लिए अपने पथ पिछड़े संगत (जो वेब में अच्छी बात है) रखने के लिए बहुत कम आवश्यकता है :)

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

या आपने कहानी के उस हिस्से की कल्पना कैसे की?

धन्यवाद।

^ यह सुबह की कॉफी से पहले लिखा गया था, इसलिए कृपया मुझे बताएं कि क्या आपको इसके किसी भी हिस्से के लिए अधिक सुसंगत स्पष्टीकरण की आवश्यकता है। :)

सबसे पहले आप लोगों का धन्यवाद कि आपने मेरे मुद्दे की समीक्षा के लिए समय निकाला।

@timneutkens हाँ assetPrefix की प्राथमिकता basePath , ठीक यही हमने शुरुआत में चर्चा की है। जब मैंने देखा कि मुझे कितनी फाइलें बदलनी हैं, तो मुझे लगा कि दूसरा रास्ता साफ होगा। लेकिन मैं पहले समाधान के लिए रोलबैक करूंगा। चलो इसे पूरी तरह से अलग रखें, कोई समस्या नहीं है। मैं बस जोर-जोर से सोच रहा था।

आपके विस्तृत जवाब के लिए @alexindigo Thx मुझे आपके सवालों का जवाब देने की कोशिश करें your

निश्चित नहीं है कि वर्तमान एसेटप्रिफ़िक्स के साथ आपके लिए वास्तव में क्या काम नहीं किया गया है

मुझे यहां दो समस्याएं हैं:

1. मैं वर्तमान परियोजना में कई डोमेन और न ही उप डोमेन के साथ काम नहीं कर सकता। (डोमेन प्रतिबंध और वाइल्डकार्ड SSL प्रमाणपत्र नहीं)
2. किसी एकल डोमेन पर assetPrefix वर्तमान कार्यान्वयन के लिए प्रॉक्सी रूटिंग, स्टैटिक फ़ाइलों आदि में अधिक समायोजन की आवश्यकता होती है। हम basePath परिचय देकर इस समायोजन को कम कर सकते हैं। यह कुछ भी नहीं टूटेगा और यह जटिलता नहीं बढ़ाएगा क्योंकि आपको basePath प्रदान नहीं करना है।

आवेदन का कोई पता नहीं है कि इसे कहां तैनात किया जा सकता है

हमारे यहाँ एक ही लक्ष्य है! हम अपने वर्तमान समाधान में गतिशील रूप से एसेटप्रिफ़िक्स को परिभाषित कर रहे हैं। यह प्रॉक्सी द्वारा अनुरोध हेडर के माध्यम से प्रदान किया जाता है।

फिर यह वर्तमान में काम करने के तरीके से कैसे अलग है?

राउटर को संदर्भपैथ के बारे में पता होगा और कस्टम कोड की मात्रा को कम करेगा।

प्रत्येक द्वीप को पता होना चाहिए (और शायद यह तय करना) कि वह स्वयं तैनाती बेसपाट है? या द्वीप ए को तैनाती पथ का अज्ञेय होना चाहिए?

यह होना नहीं है। डेवलपर को यहां स्वतंत्रता होनी चाहिए। बेसपाथ को गतिशील रूप से एसेटप्रिफ़िक्स के समान प्रदान करना संभव होना चाहिए।

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

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

और चीजों को तैनात करने के आधुनिक तरीके से, इसका मतलब है कि जब आप नए को जोड़ना चाहते हैं तो सभी द्वीपों को फिर से तैयार करना।

मुझे एक कारण दिखाई नहीं दे रहा है। मैं यह भी सोच सकता हूं कि कुछ ज़ोन में बेसपैथ और कुछ नहीं हैं। और हो सकता है कि कुछ ऐप बिना मल्टीप्ल सेटअप के भी बेसपाट कॉन्फिग का इस्तेमाल करेंगे।

@alexindigo क्या आप pls हमें एक दो असली द्वीप के साथ प्रदान कर सकते हैं, जो कि अगली बार प्रदान किए जाते हैं। इसलिए मैं इसे कार्रवाई में देख सकता हूं? मैंने एक खोजने की कोशिश की, लेकिन _next अनुरोधों के साथ आपके डोमेन पर एक पृष्ठ नहीं मिला
क्या आपके सभी द्वीपों में समान विन्यास है?
"assetPrefix":"https://static.trulia-cdn.com/javascript"

@tomaswitek

मैं वर्तमान परियोजना में कई डोमेन और न ही उप डोमेन के साथ काम नहीं कर सकता। (डोमेन प्रतिबंध और वाइल्डकार्ड SSL प्रमाणपत्र नहीं)

ओह, तो आप सीडीएन को शास्त्रीय अर्थों में उपयोग नहीं करते हैं, लेकिन सीधे प्रत्येक ऐप से प्राप्त संपत्ति पर भरोसा करते हैं? समझा।

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

Btw, यह "नहीं था, उस सुविधा को न जोड़ें" :) यह अधिक पसंद था - "शायद हम इस दृष्टिकोण के बारे में अधिक समग्र सोच सकते हैं" :)

यह होना नहीं है। डेवलपर को यहां स्वतंत्रता होनी चाहिए। बेसपाथ को गतिशील रूप से एसेटप्रिफ़िक्स के समान प्रदान करना संभव होना चाहिए।

हाँ। यह केवल तब काम करता है जब द्वीपों के बीच कोई संबंध नहीं होता है। और लगता है कि यह आपके उपयोग का मामला है। एक ही समय में, मुझे यह समझने में कठिन समय आ रहा है कि क्या उन्हें केवल स्टैंडअलोन अनुप्रयोगों का एक गुच्छा होने के बजाय द्वीप बनाते हैं, अगर वे 100% स्वतंत्र हैं? :)

हो सकता है कि आप रूटपथ को निर्यात निर्यात में भी जोड़ सकते हैं।

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

क्या आपके सभी द्वीपों में समान विन्यास है?
"एसेटप्रिफ़िक्स": " https://static.trulia-cdn.com/javascript "

हां, सभी द्वीप अपनी परिसंपत्तियों को साझा करते हैं, क्योंकि अगली बार सामग्री हैशिंग के साथ है, यह न केवल गैर-मुद्दा है, बल्कि वास्तव में बहुत फायदेमंद है। (हम प्रत्येक कलाकृति से निर्मित संपत्ति निकालते हैं और तैनाती के समय सीडीएन पर प्रकाशित करते हैं)।

और इस तरह से हमारे पास हमारे ऐप सर्वर के लिए केवल "नियमित html" अनुरोध हैं, यही कारण है कि मुझे trulia.com पर कोई "_next" पथ दिखाई नहीं देगा

द्वीप के उदाहरणों के लिए:

हमारा ताज़ा ब्रांड नया द्वीप - पड़ोसी पृष्ठ - https://www.trulia.com/n/ca/san-francisco/pacific-heights/81571 (और आप उनमें से अधिक यहां पा सकते हैं: http: //www.trunia com / आस-पड़ोस)
यह द्वीप सभी /n/* रास्तों के लिए जिम्मेदार है।

और एक अन्य द्वीप हमारा लॉगिन पेज है - https://login.trulia.com/login - यह अलग-अलग डोमेन की तरह दिखता है, लेकिन यह वास्तव में नहीं है, यह अलग-अलग कारणों के लिए इस तरह दिखता है, लेकिन तकनीकी रूप से यह एक ही तैनाती है। :)
और यह द्वीप /login , /signup जैसे यूआरएल को संभालता है।

यदि आपके और प्रश्न हैं तो मुझे बताएं।

@alexindigo आपके उदाहरणों के लिए बहुत-बहुत धन्यवाद।
उदाहरण ay anaylzing के बाद मेरे कुछ सवाल हैं

आप अभी भी हर द्वीप के लिए सर्वर रेंडरिंग करते हैं, लेकिन आप एक सामान्य सीडीएन में संपत्ति के रूप में अधिक संपत्ति निकालने की कोशिश करते हैं?

क्या आप pls थोड़ा और वर्णन कर सकते हैं कि वास्तव में क्या होता है जब https://www.trulia.com/n/ca/san-francisco/pacific-heights/81571 कहा जाता है? क्या आपके प्रॉक्सी को पता है कि /n पड़ोस के अवलोकन के लिए खड़ा है और यह सही द्वीप के लिए आगे है? क्या यह किसी तरह द्वीप पर आने से पहले अनुरोध को प्रभावित करता है?

क्या आप किसी द्वीप के अंदर से निर्मित रूटिंग का उपयोग करते हैं या क्या आपके पास कोई कस्टम समाधान है?
मैं आपके द्वीप के अंदर मार्ग की जाँच करना चाहता था। दुर्भाग्यवश Neighborhood overview पास url को बदले बिना कमोबेश सिर्फ मोडल नेविगेशन है। लॉगिन में एक पूरी तरह से कस्टम समाधान प्रतीत होता है।

मुझे उम्मीद है कि मैं इस टिप्पणी में आपके सभी सवालों का जवाब दूंगा your

Btw, यह "नहीं था, उस सुविधा को न जोड़ें" :) यह अधिक पसंद था - "शायद हम इस दृष्टिकोण के बारे में अधिक समग्र सोच सकते हैं" :)

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

हाँ। यह केवल तब काम करता है जब द्वीपों के बीच कोई संबंध नहीं होता है। और लगता है कि यह आपके उपयोग का मामला है। एक ही समय में, मुझे यह समझने में कठिन समय आ रहा है कि क्या उन्हें केवल स्टैंडअलोन अनुप्रयोगों का एक गुच्छा होने के बजाय द्वीप बनाते हैं, अगर वे 100% स्वतंत्र हैं? :)

मैंने कभी नहीं लिखा और न ही कहा कि मैं एक "द्वीप" समाधान खोजता हूं। मेरे पास सिर्फ @timneutkens के साथ एक चैट थी जहां मैंने अपनी समस्या का वर्णन किया और टिम का जवाब मूल रूप से next.js बेसपेथ्स का समर्थन नहीं करता है। और थोड़ी सी गुगली करने के बाद मुझे एहसास हुआ कि मैं इसे खोजने वाला अकेला नहीं हूं। इसलिए मुझे लगा कि मैं थोड़ा योगदान दे सकता हूं। बाद में टिम ने मुझे एक प्रतिक्रिया देने के लिए पिंग किया और मैं आपकी प्रतिक्रिया के लिए बहुत आभारी हूं।

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

यदि आप बिल्ड समय पर मार्गों को निर्यात करना चाहते हैं और उन्हें अन्य द्वीपों के लिए उपलब्ध कराना चाहते हैं तो संभवत: एकमात्र सीधा तरीका संभवत: कॉन्फ़िगरेशन में बेसपाट को हार्डकोड करना है। मुझे आपका बिंदु पता है। दूसरी तरफ, क्या वाकई ऐसी समस्या है? आप अभी भी विभिन्न डोमेन और पोर्ट पर एप्लिकेशन को तैनात कर सकते हैं और आप प्रत्येक env के लिए एक ही बेसपाथ का उपयोग कर सकते हैं।

सुप्रभात @tomaswitek :)

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

आप अभी भी विभिन्न डोमेन और पोर्ट पर एप्लिकेशन को तैनात कर सकते हैं और आप प्रत्येक env के लिए एक ही बेसपाथ का उपयोग कर सकते हैं।

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

और यह अधिक संकीर्ण समस्या की तरह लगता है जिसे हम कम दीर्घकालिक दुष्प्रभावों के साथ हल कर सकते हैं।

और यह हमें और भी आगे ला सकता है, जैसे कि यदि हम एसेटपाथ प्रति एसेट को कॉन्फ़िगर कर सकते हैं (जैसे कि किसी प्रकार का अगला.कॉन्फ़िग मैप) - यह हमें ऐप्स के बीच साझा संपत्ति रखने की अनुमति देगा, जिससे प्रदर्शन और अन्य चीजों में सुधार होगा।

और उस सुविधा के लिए खुला पीआर है। ;) / cc @timneutkens लगता है जैसे उस पिल्ले के वापस आने का समय हो गया है। :)

यदि आप इसे जल्द ही किसी भी समय नहीं जोड़ने जा रहे हैं, तो क्या हमें एक उदाहरण एक्सप्रेस आधारित सर्वर मिल सकता है। इसे रीडमी में जोड़ा गया है जो यह करता है और काम करता है? मैंने कुछ कोशिश की है जो इन मुद्दों में इधर-उधर हो रही है लेकिन उन्हें काम करने के लिए नहीं मिला है। धन्यवाद।

नमस्ते @ मेरे पास एक काम करने वाला कांटा है जिसका हम पहले से ही उपयोग कर रहे हैं: https://github.com/panter/next.js/pull/2
मैं इस सुविधा के लिए पीआर खोलने के लिए निवेश करने के लिए भी तैयार हूं।
@timneutkens @alexindigo इस समस्या को हल करने का एक और तरीका है?
अगर हमें basePath config की आवश्यकता नहीं है, तो क्या आप assetPath का उपयोग करके हमें एक न्यूनतम उदाहरण दे सकते हैं?

मेरी कंपनी भी इसके खिलाफ आ रही है।

हम धीरे-धीरे एक विरासत ऐप, अनुभाग द्वारा अनुभाग, और Next.js. की जगह ले रहे हैं

एक सरलीकृत उदाहरण के रूप में:

| URL | ऐप |
| --- | --- |
| example.com | विरासत |
| example.com/shop | अगला |
| example.com/search | विरासत |
| example.com/members | अगला |

इसका मतलब है कि हम चाहते हैं कि

यह भी ध्यान देने योग्य है कि हम अभी उपयोग नहीं कर रहे हैं, इसलिए हम now.json रूटिंग का लाभ नहीं उठा सकते हैं। हमारे पास अपना स्वयं का लोड बैलेंसर है जो पूरे डोमेन के सामने बैठा है और फिर सबपथ पर आधारित यातायात को पार कर रहा है।

हम एक कस्टम सर्वर (hapi) का भी उपयोग कर रहे हैं, इसलिए यह अच्छा होगा यदि हम कस्टम सर्वर के भीतर भी यहाँ जो कुछ भी बना सकते हैं उसका लाभ उठा सकें।

हो सकता है कि now.config.json सेटिंग्स का कुछ संयोजन हो या माइक्रो-प्रॉक्सी का कुछ उपयोग हम इसी चीज़ को पूरा करने के लिए कर सकते हैं, लेकिन हमने अभी तक सही संयोजन का पता नहीं लगाया है।

हम चल रहे हैं, मुझे लगता है, कई वैधानिक रूप से निर्यात किए गए Next.js ऐप्स के साथ यही समस्या अब v2 पर होस्ट की गई है।

| URL | ऐप |
| - | - |
| example.com | अगला |
| example.com/dashboard | अगला |

जैसी कि उम्मीद थी, रूट ऐप ठीक काम करता है। हालांकि चीजें दूसरे में भी जाग जाती हैं। वर्तमान में हम next/link लपेट रहे हैं, जो assetPrefix के साथ मिलकर समस्या का अधिकांश हल करता है:

export default ({ children, href, ...rest }) => (
      <Link href={process.env.NODE_ENV === "production" ? `/dashboard${href}` : href} {...rest}>
        {children}
      </Link>
);

हालाँकि, यह prefetch तोड़ देता है क्योंकि तब यह गलत URL पर .js फ़ाइलों की तलाश करने की कोशिश करता है:

• वास्तविक फ़ाइल URL: https://www.jirafe.io/dashboard/_next/static/Ya8O0iFjG~RJGGDYsrQ8S/pages/team/overview.js
• प्रीफ़ेट की गई फ़ाइल URL: https://www.jirafe.io/dashboard/_next/static/Ya8O0iFjG~RJGGDYsrQ8S/pages/dashboard/team/overview.js

हमारा वर्तमान समाधान prefetch को अक्षम करना है, जो आदर्श नहीं है।

इस पर क्या स्थिति है?

इसके अलावा इस पर एक अद्यतन के लिए देख रहे हैं।

@timneutkens यदि समुदाय रुचि रखता है तो मैं इसके लिए एक पीआर खोलने के लिए निवेश करने के लिए तैयार हूं। हम पहले से ही उत्पादन में एक समाधान (https://github.com/panter/next.js/pull/1) का उपयोग कर रहे हैं और हम इससे बहुत खुश हैं।

हमें इसके लिए एक समाधान की भी आवश्यकता है

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

इससे भी प्रभावित हुआ। एक उपनिर्देशिका पथ के तहत अगली परियोजना को चलाने की आवश्यकता है। आधिकारिक सुविधा के लिए आगे देख रहे हैं। क्या कोई ईटीए है?

एपीआई

कैसे हालचाल है? : डी

कृपया थ्रेड को स्पैम न करें और मुद्दे पर ही GitHub की on सुविधा का उपयोग करें।

@timneutkens क्या आप कोई और जानकारी प्रदान कर सकते हैं? एपीआई क्या है जो इसे अप्रचलित कर देगा? आप "जल्द ही" क्या मानते हैं? धन्यवाद।

यह वास्तव में मल्टी-ज़ोन से संबंधित नहीं हो सकता है लेकिन यह मदद कर सकता है ...

मैंने कस्टम सर्वर बनाकर और प्रॉक्सी मिडलवेयर का उपयोग करके इसके समान कुछ हल किया

उदाहरण के लिए: @Zertz
कृपया ध्यान दें: आपको अभी भी लिंक समस्या को हल करने की आवश्यकता है - फिर से, मैंने इसे एक लिंक घटक बनाकर और उपसर्ग को एप्लिकेशन के माध्यम से कॉन्फ़िगर करके पास किया है और यदि उपसर्ग मौजूद है तो उपयोग करें या कुछ भी उपयोग न करें, स्थिर छवियों के लिए समान।

const proxy = require('http-proxy-middleware');

app.setAssetPrefix('/dashboard');

  // Express custom server
  // Proxy so it works with prefix and without...
  // So if asset prefix is set then it still works
  const server = express();
  server.use(
    proxy('/dashboard', {
      target: 'http://localhost:3000', 
      changeOrigin: true,
      pathRewrite: {
        [`^/dashboard`]: '',
      },
    }),
  );

मैं जिस प्रस्ताव का उल्लेख कर रहा था वह # 7329 है

मैं जिस प्रस्ताव का उल्लेख कर रहा था वह # 7329 है

@timneutkens
क्या आप pls इस बारे में अधिक जानकारी प्रदान कर सकते हैं कि प्रस्तावित हुक हमारी बेसपाथ समस्याओं को कैसे हल करेगा?
और राउटर पुनर्निर्देश के बारे में Router.push('/about') क्या यह एक हुक के साथ भी बदला जाएगा?

आपके समय के लिए धन्यवाद 😏

राउटर एपीआई भी बदल जाएगा, क्योंकि इसे लिंक करने के लिए एक घटक की आवश्यकता होगी। उस समय आप url के लिए सापेक्ष पथ का उपयोग कर सकते हैं।

जब हम कोई समाधान प्राप्त कर सकते हैं या कम से कम इसके लिए वर्कअराउंड पर कोई अपडेट?

किसी भी अद्यतन को पोस्ट करने के बजाय प्रारंभिक मुद्दे पर initial का उपयोग करें।

@ MMT-LD आपका समाधान मेरे लिए काम करता है, लेकिन अब हर लिंक पर क्लिक करें या राउटर धक्का घटना पृष्ठ पुनः लोड करें Your

मैंने @Zertz के समाधान की कोशिश की और यह पूरी तरह से काम किया!
इसके अलावा, मैं पूर्वनिर्मित रास्तों पर आउटपुट फ़ाइलों को कॉपी करके prefetch समस्या को ठीक कर सकता था।
https://github.com/fand/MDMT/blob/master/scripts/copy-preload.js

... यह एक गंदी चाल है, लेकिन यह वैसे भी काम कर रही है

@nicholasbraun

अब हर लिंक पर क्लिक करें या राउटर पुश इवेंट पेज को फिर से लोड करता है or

मेरे पास यह मुद्दा था, लेकिन लिंक पर 'के रूप में' पैरामीटर का उपयोग करके तय किया गया था, इसलिए लिंक आंतरिक फ़ाइल को इंगित करता है, लेकिन 'के रूप में' पथ के सापेक्ष है
उदाहरण के लिए:
<Link href={"/${item.link}"} as={"./${item.link}"}>

@nicholasbraun

आपके समाधान का तरीका मेरे लिए काम करता है, लेकिन अब हर लिंक पर क्लिक करें या राउटर धक्का पृष्ठ को फिर से लोड करता है for

इस तरह का मेरा मतलब है। यह स्मृति से है .... लेकिन मुझे यकीन है कि आप नीचे से क्या जरूरत है पाने के लिए नहीं कर सकते।

// WithConfig component
import getConfig from 'next/config';

const { publicRuntimeConfig } = getConfig();

const WithConfig = ({ children }) =>
  children && children({ config: publicRuntimeConfig });

export default WithConfig;

// Extended Link component

 import React from 'react';
import PropTypes from 'prop-types';
import Link from 'next/link';
import { WithConfig } from '../WithConfig';
/* 
    <Link> component has two main props:
    href: the path inside pages directory + query string. e.g. /page/querystring?id=1
    as: the path that will be rendered in the browser URL bar. e.g. /page/querystring/1

*/

const NextLink = ({
  browserHref,
  pagesHref,
  whatever,
}) => {
  return (
    <WithConfig>
      {({ config: { pathPrefix } = {} }) => (
        <Link
          as={pathPrefix ? `${pathPrefix}${browserHref}` : browserHref}
          href={pagesHref}
          passHref
        >
          <a>{whatever}</a> // this bit is up to you - children or whatever
        </Link>
      )}
    </WithConfig>
  );
};

NextLink.propTypes = {
  browserHref: PropTypes.string.isRequired,
  pagesHref: PropTypes.string,
};

NextLink.defaultProps = {
  pagesHref: undefined,
};

export default NextLink;

उपयोग:

import NextLink from '../NextLink'

<NextLink browserHref={`/page/1`} pagesHref={`/page?querystring=1`} whatever='I'm the link' />

सौभाग्य: स्माइली:

जैसा कि useLink RFC अब अस्वीकृत (# 7329) है और basePath समर्थन होने से हमें बहुत मदद मिलेगी, क्या Next.js PR को इसे लागू करने की स्वीकृति देकर खुश है? मैं इसे करने को तैयार हूं।

@Tomaswitek द्वारा इस कार्यान्वयन को देखते हुए , यह सही दिशा में जा रहा है, सबसे महत्वपूर्ण बात यह है कि राउटर basePath अवगत हो। क्या अन्य गैर-स्पष्ट चीजें हैं जो basePath समर्थन को मुश्किल बना देंगी?

कुल मिलाकर, मुझे लगता है कि डिजाइन स्पष्ट है, बस एक एकल चर है:

module.exports = {
  basePath: '/demo'
}

assetPrefix साथ सहभागिता यहां अच्छी तरह से परिभाषित की गई है: https://github.com/zeit/next.js/issues/4998#issuecomment -414978297।

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

यह समस्या 2017 के आसपास की है, क्या कोई वर्कअराउंड है? या हमारे बेसपाथ अनुरोध के लिए एक आधिकारिक प्रतिक्रिया?

तो इस काम को assetPrefix और एक कस्टम <Link> के संयोजन के साथ करने की कोशिश करने के बाद जैसे कि https://github.com/zeit/next.js/issues/4998#issuitomment में सुझाव दिया गया है। -464345554 या https://github.com/zeit/next.js/issues/4998#issuecomment -521189412, मेरा मानना ​​है कि यह नहीं किया जा सकता है, दुर्भाग्य से।

assetPrefix को परिभाषित करना अपेक्षाकृत सरल था, next.config.js में कुछ इस तरह:

const assetPrefix = process.env.DEPLOYMENT_BUILD ? '/subdir' : '';

module.exports = {
  assetPrefix,
  env: {
    ASSET_PREFIX: assetPrefix,
  },
}

अगला चरण कस्टम Link घटक है। पहला विचार, उदाहरण के लिए https://github.com/zeit/next.js/issues/4998#issuecomment -464345554 में दिया गया है, इस प्रकार (सरल) में href उपसर्ग करना है:

export default ({ children, href, ...rest }) => (
  <Link href={`${process.env.ASSET_PREFIX}${href}`} {...rest}>
    {children}
  </Link>
);

जैसा कि इस थ्रेड में अन्य लोगों द्वारा बताया गया है, यह प्रीफ़िटिंग को तोड़ता है क्योंकि अनुरोध अचानक / subdir /example.js में होते हैं - अन्य "उपदिर" नहीं होना चाहिए। लेकिन हमारे कस्टम Link घटक के साथ, हम /subdir/example लिए href सेट कर रहे हैं, इसलिए कोई आश्चर्य नहीं कि Next.js pages/subdir/example.js पृष्ठ के बंडल का अनुरोध कर रहे हैं।

तो ठीक है, समस्याग्रस्त प्रीफ़ैचिंग दुनिया के अंत की तरह ध्वनि नहीं करता है (हालांकि यूएक्स काफी बदसूरत है) लेकिन हमारे ऐप में, चीजें खराब हो जाती हैं जैसे कि हम Next.js 9 के डायनामिक रूटिंग का उपयोग कर रहे हैं। उसके लिए, हमें as ठीक से सेट करने की आवश्यकता है ताकि कस्टम Link घटक का विकास निम्न प्रकार हो:

export default ({ children, href, as, ...rest }) => (
  <Link 
    href={`${process.env.ASSET_PREFIX}${href}`}
    as={`${process.env.ASSET_PREFIX}${as}`}
    {...rest}
  >
    {children}
  </Link>
);

उपयोग है:

<CustomLink href='/post/[id]' as='/post/1'>...</CustomLink>

जो परिवर्तित हो जाता है:

<Link href='/subdir/post/[id]' as='/subdir/post/1'>...</Link>

और यह मेरे लिए काम नहीं कर रहा था जब अब पर तैनात किया गया था - https://deployment-id.now.sh/subdir/post/1 404 करने के लिए नेतृत्व करने के लिए नेविगेट करने की कोशिश कर रहा हूं। मुझे पूरी तरह से यकीन नहीं है कि, शायद यह @now/next बिल्डर के साथ भी एक मुद्दा है ( अद्यतन करें : यह https://github.com/zeit/next.js/pull/8426#issuecomment-522801831) के कारण है, लेकिन अंततः, हम /subdir/post/[id] मांगने पर Next.js के राउटर को भ्रमित कर रहे हैं।

इस धागे में एक और उदाहरण है, https://github.com/zeit/next.js/issues/4998#issuecomment -521189412, यह उपसर्ग केवल उसी तरह है , न कि href, इस तरह (सरलीकृत):

export default ({ children, href, as, ...rest }) => (
  <Link href={href} as={`${process.env.ASSET_PREFIX}${as}`} {...rest}>
    {children}
  </Link>
);

लेकिन जो ब्राउज़र में इस त्रुटि को फेंक देगा:

आपका <Link> as मूल्य href मूल्य के साथ असंगत है। यह अमान्य है।

यह https://github.com/zeit/next.js/issues/7488 पर रिपोर्ट की गई समस्या है

इस सब के बाद, मुझे नहीं लगता कि basePath जैसे कुछ का समर्थन किया गया है, जब तक मैं मदद करने के लिए खुश हूं।

@borekb मैं भी मदद करने के लिए तैयार हूं जैसा कि मैंने पहले भी दो बार उल्लेख किया है। मैंने अब तक देखे गए सभी वर्कअराउंड समस्या के केवल एक हिस्से को हल करते हैं। अभी हम उत्पादन में next.js के एक कांटे का उपयोग कर रहे हैं जो बेसपाट को लागू करता है।

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

@ यह क्या अभी भी मामला है या एपीआई के लिए नया प्रस्ताव बंद था? https://github.com/zeit/next.js/issues/7329

Btw। कल यह ठीक एक वर्ष होगा जब मैंने इस मुद्दे को खोला year

एक अपेक्षाकृत जंगली विचार src/pages जैसी किसी चीज़ में पृष्ठों का होना और फिर उन्हें उचित स्थान पर सम्‍मिलित करना है। उदाहरण के लिए:

• myapp.example.com लिए परिनियोजित करने के लिए, मैं src/pages से pages सिमिलिंक करूंगा
• example.com/myapp लिए परिनियोजित करने के लिए, मैं src/pages pages/myapp सम्‍मिलित करूंगा

कस्टम <Link> घटक और assetPrefix संयोजन में, यह _could_ काम करता है लेकिन मैं इसे आज़माने के लिए पर्याप्त बहादुर नहीं हूं।

उसके साथ कोई अपडेट?

basePath समर्थन पर कोई प्रगति? :)

@nicholasbraun

अब प्रत्येक लिंक पर क्लिक करें या राउटर पुश ईवेंट पृष्ठ को frowning_face पुनः लोड करता है

मेरे पास यह मुद्दा था, लेकिन लिंक पर 'के रूप में' पैरामीटर का उपयोग करके तय किया गया था, इसलिए लिंक आंतरिक फ़ाइल को इंगित करता है, लेकिन 'के रूप में' पथ के सापेक्ष है
उदाहरण के लिए:
<Link href={"/${item.link}"} as={"./${item.link}"}>

आपने मेरा दिन बचाया! :)))

मैं Router.push(`/route`, `${process.env.BASE_PATH}route`); साथ भी ऐसा ही कर रहा हूं

@nicholasbraun

अब हर लिंक पर क्लिक करें या राउटर पुश इवेंट पेज को फिर से लोड करता है or

मेरे पास यह मुद्दा था, लेकिन लिंक पर 'के रूप में' पैरामीटर का उपयोग करके तय किया गया था, इसलिए लिंक आंतरिक फ़ाइल को इंगित करता है, लेकिन 'के रूप में' पथ के सापेक्ष है
उदाहरण के लिए:
<Link href={"/${item.link}"} as={"./${item.link}"}>

यह समाधान अगले 9 फ़ाइल आधारित रूटिंग के साथ काम नहीं करता है। /route/[id] , ${process.env.BASE_PATH}/route${id} इस त्रुटि को फेंकता है

यह टिप्पणी समस्या को बहुत अच्छी तरह से समझाती है।

हालांकि मैंने कुछ लोगों से चर्चा की है कि कैसे समाधान यहाँ पूर्व-भंग को तोड़ते हैं। हमारे लिए एक और महत्वपूर्ण मुद्दा है।

अगले 9 के साथ, आपके href में एक एसेटप्रिफ़िक्स का उपयोग करके next _always_ सर्वर मार्ग का प्रदर्शन करता है। मैंने इस अंक में एक रिप्रोडक्शन रेपो बनाया है जो इसे हो रहा है।

यह अनिवार्य रूप से हमारे अपोलो क्लाइंट कैश को तोड़ता है, क्योंकि यह हर मार्ग पर फिर से बनाया गया है।

मुझे लगता है कि क्रियान्वयन अंतर्निहित पृष्ठ href तुलना में एक संपत्तिप्रेफिक्स के बिना कर रहा है, अगले मार्गों में href (जिसमें एक एसेटप्रिफ़िक्स शामिल है) - जिसके परिणामस्वरूप एक गहरा मार्ग है।

जैसे यदि आप href /prefix/page (अंतर्निहित पृष्ठ केवल /page ) हैं और आपका अगला href मार्ग /prefix/page/[id] (क्योंकि उपसर्ग के बिना यह 404 होगा) यह एक अलग मार्ग है और एक उथला मार्ग संभव नहीं है।

एक्सप्रेस मार्गों के साथ मिनट में वर्कअराउंड को देखते हुए

जब उपयोग करें href प्रॉप्स के साथ घटक जो बेसपैथ है, प्रीफैच काम नहीं कर रहा है।
पीएलजेड बेसपैथ और प्रीफैच का समर्थन करता है, यह भयानक होगा

मैं वास्तव में इसका इस्तेमाल कर सकता हूं। मैं एक एकल सर्वर स्रोत से कई ऐप चला रहा हूं और प्रत्येक अपने स्वयं के web/appX/{next project files} में अलग हो गया है। बेसपाठ पर अधिक नियंत्रण रखना बहुत अच्छा होगा। मुझे अब इसके लिए वर्कअराउंड का पता चला है, लेकिन यह बहुत सुंदर नहीं है।

स्थिर निर्यात को भी basePath also की आवश्यकता होती है

लगता है कामयाबी 👏

{
  experimental:{
    basePath: '/some/dir',
  }
}

दुर्भाग्य से हमारे लिए यह बहुत बुरी सीमा है :(

हमारे पास एक रिवर्स प्रॉक्सी के पीछे सभी ऐप्स हैं, इसलिए पथों को उपसर्ग करने की आवश्यकता है (नीचे दिए गए उदाहरण में /auction-results का उपसर्ग है)

हम पहले से ही assetPrefix उपसर्ग का उपयोग करते हैं - और यह सर्वर साइड अनुरोधों के लिए ऐप्स को ठीक से चलाने की अनुमति देता है।
जैसे: mydomain.com/auction-results/ कुछ एक्सप्रेस रूटिंग का उपयोग करके ठीक काम करता है जैसे:

router.get(`/${appPrefix}/`, (req, res) => {
  nextApp.render(req, res, '/national', req.params);
});

लेकिन जब हम next/link माध्यम से क्लाइंट साइड नेवी करने की कोशिश करते हैं, जैसे:

कहाँ /auction-results आवेदन उपसर्ग है, और /national में पेज है ~pages/national

<Link href="/national" as="/auction-results/">
  <a>Goto National Page</a>
</Link>

यह कुछ नहीं करता (भूत क्लिक)

पूर्ण पृष्ठ रिफ्रेश लिंक आदर्श से कम है।

अगर कोई रास्ता है तो मैं इसके साथ मदद कर सकता हूं

इस पर कोई अद्यतन ... पिछले साल इस समय के आसपास मैं इस मुद्दे में भाग गया। अब एक साल बाद, मैं एक नए ऐप पर काम कर रहा हूं और पिछले साल मैंने जो वर्कआर्डर किए हैं, उन्हें करने के लिए ... 'प्रोडक्शन-रेडी' रिएक्शन fw के लिए थोड़े चिंताजनक। बेसपेथ्स एक वेनिला सुविधा होनी चाहिए।

इस पर कोई अद्यतन ... पिछले साल इस समय के आसपास मैं इस मुद्दे में भाग गया। अब एक साल बाद, मैं एक नए ऐप पर काम कर रहा हूं और पिछले साल मैंने जो वर्कआर्डर किए हैं, उन्हें करने के लिए ... 'प्रोडक्शन-रेडी' रिएक्शन fw के लिए थोड़े चिंताजनक। बेसपेथ्स एक वेनिला सुविधा होनी चाहिए।

मुझे यकीन नहीं है कि आप इसे पोस्ट करके क्या उम्मीद कर रहे हैं।

Next.js मेरी टीम (5 लोग) द्वारा पूर्णकालिक रूप से काम किया जा रहा है, और हम एक ही समय में कई विशेषताओं पर काम कर रहे हैं। पिछले वर्ष में हमने इन पर काम किया है:

• https://nextjs.org/blog/next-9
• https://nextjs.org/blog/next-9-0-7
• https://nextjs.org/blog/next-9-1
• https://nextjs.org/blog/next-9-1-7
• https://nextjs.org/blog/next-9-2
• https://nextjs.org/blog/next-9-3

प्रभावी रूप से Next.js एप्लिकेशन (नया और मौजूदा) बनाने में काफी छोटा, तेज और अधिक स्केलेबल है।

यदि आप एक विशेषता के लिए अपने "अपवोट" को आवाज देना चाहते हैं। प्रारंभिक धागे पर on सुविधा का उपयोग करें।

मैं निश्चित रूप से सहमत हूं कि basePath एक अंतर्निहित सुविधा होनी चाहिए। यह पहले से ही रोडमैप पर है और मैंने एक प्रारंभिक पीआर भी लिखा था, जिसे आप थ्रेड पर वापस पढ़कर देख सकते थे।

यहां पीआर: https://github.com/zeit/next.js/pull/9872 है

यदि आप इस सुविधा को बनाने के लिए आर्थिक रूप से योगदान करना चाहते हैं, तो एंटरप्राइज़ @vercel.com तक पहुँचने में संकोच न करें।

इस पर स्थिति क्या है? हम वास्तव में इस पर निर्भर हैं: /

@Sletheren basePath समर्थन अभी प्रायोगिक है, अपने उल्लू जोखिमों पर उपयोग करें।

सीएफ https://github.com/zeit/next.js/pull/9872

@Sletheren basePath समर्थन अभी प्रायोगिक है, अपने जोखिम पर उपयोग करें।

सीएफ # 9872

@ मार्टेपी मैंने पहले ही इसे देख लिया था, लेकिन इसके लिए। मेरा मामला basePath केवल एक नहीं है, यह कई आधार हो सकते हैं, क्योंकि हम अलग-अलग "URL" के माध्यम से अपने ऐप की सेवा करते हैं और बिल्ड समय के दौरान basePath सेट करना एक विकल्प नहीं है (भले ही इसके पास है एक स्ट्रिंग के बजाय पथों की एक सरणी का समर्थन करने के लिए)

@timneutkens अपडेट के लिए धन्यवाद। क्या आप एक और अपडेट देने के लिए इतने दयालु होंगे। यह हमारे लिए एक प्रमुख विशेषता है और हमें यह जानना होगा ...

1. क्या यह केवल उद्यम होगा (संपर्क उद्यम बिक्री के लिए आपका संदर्भ कुछ जलन पैदा करता है)?

2. यह रोडमैप पर लगता है, पीआर के अनुसार इसे फिर से हटाया नहीं जाएगा; क्या आप कुछ संकेत दे सकते हैं अगर अगले महीनों में बिना किसी आश्चर्य के खुले स्रोत संस्करण की तरह इस फीचर के इर्द-गिर्द निर्माण करना सुरक्षित है और दूसरे को पूरी तरह से समर्थन के बाद एक सप्ताह के लिए हमने कुछ यादृच्छिक बिक्री वाले लोगों के साथ मनमानी कीमतों के बारे में बातचीत की?

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

अपनी समझ के लिए धन्यवाद और अपनी प्रतिक्रिया के लिए fwd देख रहे हैं।

FWIW, मुझे अब यह काम कर रहा है और अन्य लोगों द्वारा ड्राइविंग के लिए:

इसे अपने next.config.js :

module.exports = {
  experimental: {
    basePath: '/custom',
  },
}

फिर, मुझे सर्वर को पुनरारंभ करने और अपने वेब सर्वर मिडलवेयर को ठीक से सेट करने की आवश्यकता थी:

मैं एक कस्टम पथ के माध्यम से सभी अनुरोधों को पकड़ता हूं, उदाहरण के लिए। app.use('/custom', (req, res...) => { ... और फिर (जो महत्वपूर्ण था) मुझे उस सिस्टम के URL पर प्रॉक्सी करने की आवश्यकता है जहां नेक्स्ट चल रहा है (इसलिए आपके कंटेनर ऑर्केस्ट्रेशन का आंतरिक पता और फिर से संबंधित पथ के साथ यदि आप http-proxy => उदा। ... target: 'http://next:3000/custom ), इसलिए कस्टम पथ के बिना केवल होस्ट नहीं। यदि आप http-proxy-middleware करते हैं तो आपको इसकी आवश्यकता नहीं है।

यह काफी ठीक है, मुझे उम्मीद है कि इस सुविधा के लिए किसी ईई लाइसेंस की आवश्यकता नहीं होगी। यदि आपकी टीम को इस सुविधा को परिपक्व बनाने के लिए किसी भी मदद की आवश्यकता है, तो कृपया हमें बताएं, शायद हम मदद कर सकें!

संपादित करें: बस नेक्स्ट के प्रोडक्शन मोड के साथ भी यह कोशिश की है और यह भी काम करने लगता है।

@timneutkens अपडेट के लिए धन्यवाद। क्या आप एक और अपडेट देने के लिए इतने दयालु होंगे। यह हमारे लिए एक प्रमुख विशेषता है और हमें यह जानना होगा ...

1. क्या यह केवल उद्यम होगा (संपर्क उद्यम बिक्री के लिए आपका संदर्भ कुछ जलन पैदा करता है)?
2. यह रोडमैप पर लगता है, पीआर के अनुसार इसे फिर से हटाया नहीं जाएगा; क्या आप कुछ संकेत दे सकते हैं अगर अगले महीनों में बिना किसी आश्चर्य के खुले स्रोत संस्करण की तरह इस फीचर के इर्द-गिर्द निर्माण करना सुरक्षित है और दूसरे को पूरी तरह से समर्थन के बाद एक सप्ताह के लिए हमने कुछ यादृच्छिक बिक्री वाले लोगों के साथ मनमानी कीमतों के बारे में बातचीत की?

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

अपनी समझ के लिए धन्यवाद और अपनी प्रतिक्रिया के लिए fwd देख रहे हैं।

@ पे-एस मुझे लगता है कि आप मेरी पोस्ट को गलत समझ रहे हैं।

अब के रूप में कोई "एंटरप्राइज नेक्स्ट.जेएस संस्करण" नहीं है। मैं कई मौकों का जिक्र कर रहा था, जहां बाहरी कंपनियां कम समय में इस तरह की सुविधाओं के निर्माण के लिए परामर्श देने के लिए पहुंची थीं। ट्यूलिया के सहयोग से ईजी जोन समर्थन बनाया गया था।

यह सुविधा अभी भी काम कर रही है और रोडमैप पर है। सभी सुविधाओं पर काम किया जा रहा है, वे खुले स्रोत हैं, जैसे मैंने कहा कि Next.js. का कोई उद्यम संस्करण नहीं है रोडमैप पर हमारे पास उच्च-प्रभाव वाले कार्य की कई प्राथमिकताएं हैं, इसलिए मैंने एंटरप्राइज़ @vercel.com से संपर्क करने का उल्लेख किया है, यदि आपको जल्द से जल्द इस सुविधा की आवश्यकता है / Next.js. के लिए एंटरप्राइज़ समर्थन पर चर्चा करने के लिए।

आपकी त्वरित प्रतिक्रिया और बढ़िया के लिए @timneutkens tx! फिर, हम सब में जा सकते हैं :)
अच्छा काम करते रहो!

बसपाथ समर्थन next@canary अभी बाहर है, यह अब प्रयोगात्मक नहीं है। यह जल्द ही स्थिर चैनल पर होगा।

मुझे इस पर बहुत देर हो गई है लेकिन क्या आपने मैन्युअल रूप से इसे संभालने के बजाय वास्तविक HTML <base> का उपयोग करने पर विचार किया है?

बसपाथ समर्थन next@canary अभी बाहर है, यह अब प्रयोगात्मक नहीं है। यह जल्द ही स्थिर चैनल पर होगा।

@timneutkens , इस जोड़ के लिए धन्यवाद। क्या आप जानते हैं कि गैर-प्रायोगिक बेसपैथ समर्थन आधिकारिक तौर पर कब जारी किया जाएगा?

इसके अलावा, जब मैं बेसपाट सेट करता हूं तो परिसंपत्तियां (सार्वजनिक फ़ोल्डर में स्थित) अपेक्षित url को दी जाती हैं। लेकिन, जब मैं उन्हें अपने कोड में संदर्भित करता हूं तो मुझे मैन्युअल रूप से src में आधार पथ जोड़ना होगा, क्योंकि अन्यथा उन्हें अभी भी सामान्य पथ से संदर्भित किया जाएगा। क्या यह बेसपैथ का अपेक्षित उपयोग है? मैंने एसेटप्रिफ़िक्स का उपयोग करने की भी कोशिश की है, लेकिन मेरे कोड पर इसका कोई प्रभाव नहीं पड़ा जो मैं बता सकता था।

उदाहरण :

1. next v9.4.5-canary.24
2. basePath /alerts अगले में .config.js:

const basePath = '/alerts';
module.exports = {
  basePath: basePath,
  env: {
    BASE_PATH: basePath,
  },
};

1. संपत्ति public/images/example.png
2. प्रतिक्रिया घटक में परिसंपत्ति का उदाहरण उपयोग:

const ExampleImage = () => (
  <img src={`${process.env.BASE_PATH}/images/example.png`} />
);

मेरे परीक्षणों में, यह संपत्ति के यूआरएल को अपडेट नहीं कर रहा है।

मैंने नवीनतम कैनरी स्थापित की:
npm install [email protected]

next.config.js

const isProd = process.env.NODE_ENV === 'production';

module.exports = {
  basePath: isProd ? '/example' : ''
}

सभी पृष्ठ और लिंक सही ढंग से लोड होते हैं:
http: // localhost : 3000 / उदाहरण / पोस्ट / प्री-रेंडरिंग
http: // localhost : 3000 / उदाहरण / पोस्ट / ssg-ssr
http: // localhost : 3000 / उदाहरण / पोस्ट / प्री-रेंडरिंग

लेकिन चित्र, फेवीकॉन आदि की मैपिंग नहीं की जाती है:
http: // localhost : 3000 / favicon.ico 404
http: // localhost : 3000 / images / profile.jpg 404

क्या किसी ने यह परीक्षण किया? मैंने एसेटप्रिफ़िक्स का उपयोग करने की भी कोशिश की, लेकिन यह भी काम नहीं किया।

इसके अलावा मैं उलझन में हूं, इसके लिए अंतर्निहित ब्राउज़र कार्यक्षमता का उपयोग क्यों नहीं करता हूं?
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/base

अपने अंत के साथ-साथ @kmturley में देखने के लिए धन्यवाद। यह जानकर खुशी हुई कि यह सिर्फ मैं नहीं हूं।
@timneutkens , क्या हमें इस समस्या को फिर से खोलना चाहिए / इस बग के लिए एक नया मुद्दा बनाना चाहिए?

आपको मैन्युअल रूप से छवियों को उपसर्ग करना होगा। आप बेसपैथ का उपयोग करके प्राप्त कर सकते हैं

const {basePath} = useRouter()

https://nextjs.org/docs/api-reference/next.config.js/cdn-support-with-asset-prefix

Next.js स्वचालित रूप से आपके उपसर्गों का उपयोग करेगा लिपियों में यह लोड करता है, लेकिन इसका सार्वजनिक फ़ोल्डर पर कोई प्रभाव नहीं पड़ता है;

अब, मुझे एहसास हुआ कि फाइलों को / जनता से लिंक करने के कई तरीके हैं। उदा <img/> <link/> ...
क्या यही कारण है कि हमें प्रत्येक को बेसपाथ को मैन्युअल रूप से निर्दिष्ट करना होगा?

अगर नीचे उपलब्ध जैसा कोई घटक था, तो मुझे लगता है कि यह बहुत सारे लोगों के लिए समय की बचत करेगा और भ्रम को कम करेगा?

<WithinBasePath>
  {/* automatically fixes the path with basePath */}
  <img src="/logo.png" />
</WithinBasePath>

मुझे नहीं लगता कि यह उचित है, लेकिन यही मेरा मतलब है।

// src/components/WithinBasePath/index.tsx

import React from "react"
import path from "path"
import { useRouter } from "next/router"
interface Props {}

const WithinBasePath: React.FC<Props> = (props) => {
  const { basePath } = useRouter()
  const children = [props.children].flatMap((c) => c) as React.ReactElement[]
  return (
    <>
      {children.map((child, key) => {
        let newChild = null

        switch (child.type) {
          case "img":
            newChild = React.createElement(child.type, {
              ...child.props,
              src: path.join(basePath, child.props.src),
              key,
            })
            break
          case "link":
            newChild = React.createElement(child.type, {
              ...child.props,
              href: path.join(basePath, child.props.href),
              key,
            })
            break
          default:
            newChild = React.createElement(child.type, {
              ...child.props,
              key,
            })
        }
        return newChild
      })}
    </>
  )
}
export default WithinBasePath

// pages/test.tsx

import React from "react"
import WithinBasePath from "@src/components/WithinBasePath"
interface Props {}

const test: React.FC<Props> = (props) => {
  return (
    <WithinBasePath>
      <img src="/123.jpg" />
      <link href="/abc.jpg" />
      <div>other element</div>
    </WithinBasePath>
  )
}
export default test

कक्षाओं और घटकों के साथ काम करने और यह त्रुटि प्राप्त करने के लिए const {basePath} = useRouter() उपयोग करने वालों के लिए एक हुक है:

अमान्य हुक कॉल चेतावनी

https://reactjs.org/warnings/invalid-hook-call-warning.html

आप इसका उपयोग करके काम कर सकते हैं:

import { withRouter, Router } from 'next/router'

class Example extends Component<{router: Router}, {router: Router}> {
  constructor(props) {
    super(props)
    this.state = {
      router: props.router
    }
  }
  render() {
    return (
      <Layout home>
        <Head><title>Example title</title></Head>
        <img src={`${this.state.router.basePath}/images/creators.jpg`} />
      </Layout>
    )
  }
}
export default withRouter(Example)

यदि आप बेसपैड को मार्कडाउन के साथ उपयोग करना चाहते हैं, तो ऐसा लगता है कि आपको स्ट्रिंग को खोजने और बदलने की आवश्यकता है:

const content = this.state.doc.content.replace('/docs', `${this.state.router.basePath}/docs`);
return (
<Layout>
  <Container docs={this.state.allDocs}>
    <h1>{this.state.doc.title}</h1>
    <div
      className={markdownStyles['markdown']}
      dangerouslySetInnerHTML={{ __html: content }}
    />
  </Container>
</Layout>
)

आपको मैन्युअल रूप से छवियों को उपसर्ग करना होगा। आप बेसपैथ का उपयोग करके प्राप्त कर सकते हैं

const {basePath} = useRouter()

यह समाधान हालांकि css या scss फ़ाइल में आयात की गई छवियों को ध्यान में नहीं रखता है। क्या आपके पास css या scss फ़ाइल से संपत्ति आयात करते समय आधार पथ को सेट करने का कोई उपाय है?
इस समाधान के साथ हमें यह सुनिश्चित करना होगा कि सभी चित्र या तो आईएमजी टैग, इनलाइन स्टाइल या स्टाइल टैग के माध्यम से आयात किए जाएं। यह आदर्श नहीं है, क्योंकि यह आपकी शैलियों को कई स्थानों पर लागू करने के लिए विभाजित करेगा।

@peetjvv यहां सीएसएस में पहले से मौजूद आधार के साथ संपत्ति का उपयोग करने के लिए एक उप- <CSSVariables> में घटक _app.tsx है, जो एक वैश्विक inlined injects <style> सीएसएस चर, जिसे फिर आप अपने स्टाइलशीट भर में सभी का उपयोग कर सकते युक्त तत्व।

जैसे <body> निर्माण और इंजेक्षन चर पर:

<style>
:root {
      --asset-url: url("${basePath}/img/asset.png");
}
</style>

उस बेसपाथ को पाने के लिए मैं #kmturley के दृष्टिकोण का उपयोग withRouter उपयोग करता हूं ।
यहां बताया गया है कि वह घटक कैसा दिख सकता है:

import { withRouter, Router } from "next/router";
import { Component } from "react";

export interface IProps {
  router: Router;
}

class CSSVariables extends Component<IProps> {
  render() {
    const basePath = this.props.router.basePath;
    const prefixedPath = (path) => `${basePath}${path}`;
    const cssString = (value) => `\"${value}\"`;
    const cssURL = (value) => `url(${value})`;
    const cssVariable = (key, value) => `--${key}: ${value};`;
    const cssVariables = (variables) => Object.entries(variables)
      .map((entry) => cssVariable(entry[0], entry[1]))
      .join("\n");
    const cssRootVariables = (variables) => `:root {
      ${cssVariables(variables)}
    }`;

    const variables = {
      "asset-url": cssURL(
        cssString(prefixedPath("/img/asset.png"))
      ),
    };

    return (
      <style
        dangerouslySetInnerHTML={{
          __html: cssRootVariables(variables),
        }}
      />
    );
  }
}

export default withRouter(CSSVariables);