React: एसिंक्रोनस सर्वर रेंडरिंग का समर्थन करें (रेंडरिंग से पहले डेटा की प्रतीक्षा कर रहा है)

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

ऐसे 2 मामले हैं जिनके बिना मुझे हल करना मुश्किल लगता है:

• सर्वर साइड पर, यदि आप रेंडर करने से पहले डेटा प्राप्त करना चाहते हैं तो आप डेटा पुनर्प्राप्ति को घटकों को नहीं सौंप सकते क्योंकि आपके पास इस बात की जानकारी नहीं है कि कौन सा घटक रेंडर किया जाएगा
• क्लाइंट साइड पर पहली बार जब आप प्री-रेंडर किए गए एचटीएमएल प्राप्त करने के बाद अपना आवेदन माउंट करते हैं, भले ही आपके पास सर्वर पर पुनर्प्राप्त डेटा से किसी प्रकार का कैश हो, तो आप उन डेटा को पुनर्प्राप्त करने के लिए एसिंक विधि का उपयोग करना चाहेंगे, और यह प्रतिक्रिया को रोक देगा html का पुन: उपयोग करने से।

प्रतिक्रिया-एसिंक उन समस्याओं को फाइबर, और कैश के साथ हल करते हैं। यह चाल है लेकिन मेरे विचार में वे एक समस्या को हल करने के लिए सिर्फ _hackish_ समाधान हैं जिन्हें केवल कोर में ही हल किया जा सकता है।

मुझे इस विषय पर बेहिचक रंग दें, @fdecampredon का कहना है कि componentWillMount async है और आप तुरंत कुछ भी वापस नहीं करते हैं, जब तक कि कुछ भी नहीं है, तब तक रिएक्ट को क्या प्रस्तुत करना चाहिए? यदि हां, तो अभी तक कोई डेटा नहीं होने पर रेंडर में कुछ भी क्यों नहीं लौटाया जाए? (हाँ मुझे सर्वर-साइड मिलता है) साथ ही, अगर componentWillMount आग से पहले प्रॉप्स बदल जाए तो क्या होना चाहिए?

व्यक्तिगत रूप से, ऐसा लगता है कि componentWillMount दौरान एसिंक अनुरोध भेजना गलत है जब तक कि घटक वास्तव में एक अलग ब्लैक बॉक्स न हो और लोडिंग संकेतक भी लागू न हो। जहां तक ​​​​मैं इसे समझता हूं, अधिक पारंपरिक ओओपी उदाहरणों के लिए रिएक्ट घटकों को गलत नहीं होना चाहिए। सबसे अच्छी स्थिति में, एक रिएक्ट घटक डेटा को प्रॉप्स में देखने के लिए उपकरण है, यदि यह इंटरेक्टिव है तो संभवतः यह भी बता सकता है। यह एक दृश्य है, न कि एक दृश्य और मॉडल।

मेरे कानों के लिए, यह समस्या की तरह लगता है, प्रतिक्रिया घटक एसिंक अनुरोध भेजने वाले नहीं होने चाहिए, आप सभी डेटा प्राप्त करते हैं और जब वह डेटा तैयार होता है, तभी आप React.renderComponent कॉल करते हैं। वही समाधान क्लाइंट-साइड और सर्वर-साइड। यदि कोई async अनुरोध विफल हो जाता है, तो आपको अपनी पसंद के परिणाम के साथ निरस्त करने की क्षमता भी मिलती है।

अगर मैंने कुछ गलत समझा तो मुझे खारिज करने के लिए स्वतंत्र महसूस करें, लेकिन ऐसा लगता है कि आप रिएक्ट घटकों को दृश्य और मॉडल के रूप में मान रहे हैं, जब (ऐसा लगता है) वे सिर्फ दृश्य के रूप में हैं।

मुझे इस विषय पर बेहिचक रंग दें, @fdecampredon का कहना है कि कंपोनेंटविलमाउंट

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

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

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

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

शायद यह कि मुझे चीजें गलत तरीके से मिलती हैं लेकिन वेब पर कुछ चर्चा/नमूना मुझे लगता है कि कहीं कुछ याद आ रही है:

• कुछ नमूने में मुझे ऐसा लगता है कि @petehunt ने कुछ ऐसा ही हासिल करने की कोशिश की।
• प्रतिक्रिया-नेस्टेड-राउटर willTransitionTo में कुछ समान तंत्र को बढ़ावा देता है, और कुछ चर्चाओं से मुझे लगता है कि कोई भी उचित समाधान के साथ नहीं आया है।
• RRouter डेटा को प्रीफ़ेच करने के लिए किसी प्रकार का तंत्र भी प्रदान करता है क्योंकि घटक को रेंडर/माउंट किया जा रहा है।
• और अंत में प्रतिक्रिया-async जैसा मैंने पहले कहा था।

@fdecampredon स्पष्ट होने के लिए, प्रतिक्रिया-नेस्टेड-राउटर में willTransitionTo का उद्देश्य डेटा लोड करने के लिए _not_ है, विशेष रूप से क्योंकि उस विधि से एक वादा वापस करने से वास्तव में नए UI को प्रस्तुत करना अवरुद्ध हो जाएगा, जिसे आप नहीं करना चाहते हैं जब तक आपको बिल्कुल नहीं करना है।

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

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

मेरे कानों के लिए, यह समस्या की तरह लगता है, रिएक्ट घटकों को एसिंक अनुरोध भेजने वाले नहीं होने चाहिए, आप सभी डेटा प्राप्त करते हैं और जब वह डेटा तैयार होता है, तभी आप React.renderComponent को कॉल करते हैं। वही समाधान क्लाइंट-साइड और सर्वर-साइड। यदि कोई async अनुरोध विफल हो जाता है, तो आपको अपनी पसंद के परिणाम के साथ निरस्त करने की क्षमता भी मिलती है।

अगर मैंने कुछ गलत समझा तो मुझे खारिज करने के लिए स्वतंत्र महसूस करें, लेकिन ऐसा लगता है कि आप रिएक्ट घटकों को दृश्य और मॉडल के रूप में मान रहे हैं, जब (ऐसा लगता है) वे सिर्फ दृश्य के रूप में हैं।

अगर यह सच है तो रिएक्ट थोड़े अलग टेम्प्लेटिंग सॉल्यूशन / व्यू लेयर से ज्यादा कुछ नहीं है। और यह शर्म की बात होगी क्योंकि ऐसी संभावना है। मैं वास्तव में @fdecampredon को समझता

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

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

इस समय, मुझे ऐसा लगता है कि एकमात्र तरीका रिएक्ट-एसिंक/फाइबर + फ्लक्स है। फ्लक्स के बारे में अच्छी बात यह है कि हमें सर्वर से क्लाइंट तक घटक राज्यों को परिवहन के लिए कुछ कृत्रिम कैश की आवश्यकता नहीं है (जैसे यह मूल प्रतिक्रिया-एसिंक उदाहरण में किया गया है), हम बस स्टोर्स को प्रारंभ कर सकते हैं और फिर उन्हें भेज सकते हैं html मार्कअप वाला क्लाइंट ( यह उदाहरण देखें)।

लेकिन यह समाधान वास्तव में _hackish_ है।

मुझे नहीं लगता कि यह आवश्यक रूप से कंपोनेंटविलमाउंट होना चाहिए जो कि एसिंक्स है; मुझे यकीन भी नहीं है कि यह एक जीवनचक्र घटना होनी चाहिए। असली मुद्दा यह है कि सर्वर पक्ष पर घटक पेड़ का विश्लेषण करने का कोई तरीका नहीं है जब तक कि सब कुछ एक स्ट्रिंग में प्रस्तुत नहीं किया जाता है।

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

यह दोहराता है कि हम ब्राउज़र में क्या करने में सक्षम हैं: एक वर्चुअल डोम है जिसे हम अपनी इच्छानुसार फिर से प्रस्तुत कर सकते हैं। अंतर यह है कि ब्राउज़र में डोम अपडेट निहित हो सकते हैं। सर्वर पर हमें इस बारे में स्पष्ट होना चाहिए कि हम एक स्ट्रिंग को कब प्रस्तुत करते हैं ताकि हम एसिंक डेटा के आधार पर वर्चुअल डोम में अपडेट कर सकें।

इसे हल करने के लिए मेरा आदर्श समाधान "रेंडरिंग" की अनुमति देना होगा जो कि केवल घटक पेड़ का निर्माण करेगा, फिर हम उन घटकों को खोजने के लिए पेड़ को पार करने में सक्षम होंगे जिन्हें अतिरिक्त डेटा की आवश्यकता होती है, जिससे हमें अधिक डेटा लोड करने की अनुमति मिलती है और "पुनः प्रस्तुत करना" "वह घटक सबट्री करते हैं, और फिर एक बार जब हम मार्कअप को फ्लश करने के लिए तैयार हो जाते हैं, तो हमें उस पेड़ को एक स्ट्रिंग में बदलने की अनुमति दें। — @mridgway

हाँ, यह अच्छा होगा। वर्तमान में, सर्वर-साइड पर दो बार रेंडरिंग कंपोनेंट को वर्कअराउंड के रूप में उपयोग किया जा सकता है।

मैं प्रतिक्रिया-नेक्सस को एक उदाहरण के रूप में संदर्भित करना चाहता हूं जिसे मैं प्रतिक्रिया के भीतर समर्थित होना चाहता हूं। यह अनिवार्य रूप से एक पुनर्लेखन है कि कैसे mountComponent काम करता है सिवाय इसके कि यह घटक पेड़ को वास्तव में इसे डीओएम पर घुमाने या स्ट्रिंग लिखने के बिना बनाता है। यह आपको घटक पेड़ को पार करने और पेड़ के निर्माण के दौरान एसिंक्रोनस विधियों को बंद करने की अनुमति देता है। इस कार्यान्वयन के साथ मुद्दा यह है कि यह पहले पेड़ को फेंक देता है और फिर React.renderToString वैसे भी कॉल करता है, जबकि उस प्री-रेंडर पेड़ को लेना और उसे प्रस्तुत करना/माउंट करना अच्छा होगा।

मैं इस पर कोर के भीतर काम करने को तैयार हूं, लेकिन कुछ पॉइंटर्स की आवश्यकता होगी। मुझे लगता है कि आवश्यकताओं में से एक ReactContext को विश्व स्तर पर संदर्भित नहीं कर रही है ताकि एसिंक्स मुद्दों का कारण न बने। क्या ऐसे अन्य ग्लोबल्स हैं जो इसके साथ भी मुद्दों में चल सकते हैं?

@mridgway अगर मुझे वैश्विक ReactContext गलत नहीं लगता है तो यह एक अनुकूल चीज हो सकती है और 0.14 में चली जाएगी। लेकिन मुझसे गलती हो सकती है।

@gaearon हाँ, यही वह अर्थ है जो मुझे कॉन्टेक्स्ट बहिष्करण से मिला है।

:+1: इस एटीएम के लिए react-router का उपयोग करना। @mridgway का दृष्टिकोण बहुत ही उचित लगता है।

इस मुद्दे पर थोड़ा अलग विचार यह है कि बंडलर (जैसे वेबपैक) द्वारा उत्पादित कोड भाग के एसिंक्रोनस लोडिंग को कैसे संभालना है।

जैसा कि इस टिकट में चर्चा की गई है - https://github.com/rackt/react-router/issues/1402 - एसिंक रेंडरिंग समर्थन के साथ समस्या प्रारंभिक रेंडर शून्य प्रतीत होती है क्योंकि प्रासंगिक भाग अभी तक पहले में लोड नहीं हुए हैं पास रेंडर करें, जिसके परिणामस्वरूप DOM के मूल में <noscript> होता है और एक चेकसम विफल हो जाता है। बाद में सब कुछ जल्दी से ठीक हो जाता है, लेकिन स्थानीय रूप से काम करते समय और क्षेत्र में खराब होने पर यूआई में झिलमिलाहट का परिणाम होता है, खासकर अगर डाउनलोड किए जाने वाले हिस्से उचित आकार के होते हैं (जैसे> 30 केबी)

बड़े ऐप्स को कई हिस्सों में विभाजित करने की क्षमता हमारे लिए महत्वपूर्ण है और डेटा लाने की समस्या को हल करना (हमने प्रतिक्रिया-राउटर और नेस्टेड मार्गों का उपयोग किया है जो डेटा निर्भरता लाने के लिए सर्वर पर रेंडर करने से पहले ट्रैवर्स किए जा सकते हैं) यह अंतिम टुकड़ा है हमारे सामने के छोर के लिए एक प्रतिक्रिया समाधान के लिए पूरी तरह से आगे बढ़ने से हमें रोक रहा है।

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

<WaitFor for={MyAsyncLoadedCompSignal} until={...} then={() => <MyAsyncLoadedComp ... />} /> वैकल्पिक रणनीतियों को लागू करने के लिए स्वतंत्र महसूस करें जो आपके लिए बेहतर हो सकती हैं। लेकिन ये स्वाभाविक रूप से विचाराधीन हैं और कुछ ऐसा नहीं है जिसे रिएक्ट को पेश करना चाहिए या यहां तक ​​​​कि उसे पेश करने की आवश्यकता है, इसलिए यह समुदाय के लिए सबसे अच्छा छोड़ दिया गया है।

रिएक्ट घटकों के दायरे से बाहर async सामान रखना बेहतर है, यहाँ एक उदाहरण है:

import React from 'react';
import Layout from './components/Layout';
import NotFoundPage from './components/NotFoundPage';
import ErrorPage from './components/ErrorPage';

const routes = {

  '/': () => new Promise(resolve => {
    require(['./components/HomePage'], HomePage => { // Webpack's script loader
      resolve(<Layout><HomePage /></Layout>);
    });
  }),

  '/about': () => new Promise(resolve => {
    require(['./components/AboutPage'], AboutPage => { // Webpack's script loader
      resolve(<Layout><AboutPage /></Layout>);
    });
  })

};

const container = document.getElementById('app');

async function render() {
  try {
    const path = window.location.hash.substr(1) || '/';
    const route = routes[path];
    const component = route ? await route() : <NotFoundPage />;
    React.render(component, container);
  } catch (err) {
    React.render(<ErrorPage error={err} />, container);
  }
}

window.addEventListener('hashchange', () => render());
render();

वेबपैक कोड स्प्लिटिंग देखें, स्क्रैच से रिएक्ट.जेएस रूटिंग और रिएक्ट-रूटिंग (जल्द ही आ रहा है)

@syranide मैं इस पर काम करता

अगर हमने <WaitFor ... /> दृष्टिकोण किया, तो निश्चित रूप से हमें पहले रेंडर पर एक अलग डोम मिलेगा जो अभी भी सामग्री के झिलमिलाहट/गायब होने का कारण बनता है?

अगर हमने किया दृष्टिकोण, निश्चित रूप से हम अभी भी पहले रेंडर पर एक अलग डोम प्राप्त करेंगे जो अभी भी सामग्री के झिलमिलाहट/गायब होने का कारण बन जाएगा?

यदि आप झिलमिलाहट नहीं चाहते हैं (कुछ करते हैं) तो यह केवल उन सभी हिस्सों की प्रतीक्षा करने की बात है जिन पर आप निर्भर करते हैं प्रतिपादन से पहले लोड किया गया है, वेबपैक इस आउट-ऑफ-द-बॉक्स को require.resolve ।

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

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

मैं उस पर गौर करूंगा, require.resolve बारे में मेरी समझ यह थी कि यह एक मॉड्यूल की आईडी का एक सिंक्रोनस लुकअप था और इसमें सर्वर की यात्रा शामिल नहीं थी? हम अपने चंक लोडिंग को प्रबंधित करने के लिए require.ensure का उपयोग कर रहे हैं।

हमारे कोड को फिर से देखते हुए मुझे लगता है कि हम प्रतिक्रिया-राउटर को सर्वर पर प्रस्तुत करने के बारे में सोचकर समस्या को प्रसारित कर सकते हैं लेकिन फिर मानक क्लाइंट-साइड दृष्टिकोण का पालन कर सकते हैं:

const history = new BrowserHistory();

if (typeof history.setup === "function") {
    history.setup();
}

Router.run(routes, history.location, (err, initialState, transition) => {
    React.render(<Provider redux={redux}>{() => <Router key="ta-app" history={history} children={routes} />}</Provider>, document.getElementById('ta-app'));
});

मैं उस पर गौर करूंगा, आवश्यकता के बारे में मेरी समझ। समाधान यह था कि यह एक मॉड्यूल की आईडी का एक सिंक्रोनस लुकअप था और इसमें सर्वर की यात्रा शामिल नहीं थी? हम अपने चंक लोडिंग को प्रबंधित करने के लिए requ.ensure का उपयोग कर रहे हैं।

क्षमा करें, हाँ मेरा मतलब require.ensure । कॉलबैक केवल तभी निष्पादित किया जाता है जब सभी निर्भरताएं संतुष्ट हों, इसलिए इसके अंदर केवल रेंडर/सेटस्टेट डालने की बात है।

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

आप सही हैं कि require.ensure जाने का रास्ता है, मुझे लगता है कि हमारा अंतिम मुद्दा यह था कि इसे वर्तमान में देखे जा रहे मार्ग से जोड़ा जाना चाहिए, इसलिए सीधे राउटर से जुड़ा हुआ है। प्रतिक्रिया-राउटर घटक आधारित होने के साथ जो इसे रेंडर ट्री से जोड़ता है। ऊपर मेरे हैक के बिना हम सब कुछ async लोड होने से पहले पेड़ को देखने का एक तरीका लड़ रहे हैं (या शीर्ष स्तर पर प्रासंगिक हिस्सों को लोड करने की अनुमति देने के लिए रूटिंग तर्क को डुप्लिकेट करना)।

आप सही हैं कि requ.ensure जाने का रास्ता है, मुझे लगता है कि हमारा अंतिम मुद्दा यह था कि इसे वर्तमान में जाने वाले मार्ग से जोड़ा जाना चाहिए, इसलिए सीधे राउटर से जुड़ा हुआ है। प्रतिक्रिया-राउटर घटक आधारित होने के साथ जो इसे रेंडर ट्री से जोड़ता है। ऊपर मेरे हैक के बिना हम सब कुछ async लोड होने से पहले पेड़ को देखने का एक तरीका लड़ रहे हैं (या शीर्ष स्तर पर प्रासंगिक हिस्सों को लोड करने की अनुमति देने के लिए रूटिंग तर्क को डुप्लिकेट करना)।

मैं प्रतिक्रिया-राउटर से परिचित नहीं हूं, लेकिन मैं अभी भी कल्पना करता हूं कि यह केवल setRoute(...) => require.ensure([], function() { require(...); setRoute(...); }) मामला है जो वास्तव में व्यावहारिक नहीं है इसलिए आप एक और स्तर के संकेत का परिचय देते हैं। मार्गों का नक्शा और प्रत्येक के लिए async require.ensure लोडर। एक सहायक लिखें function asyncSetRoute(...) { loadRoute(route, function() { setRoute(...); }} , अब आप इसके बजाय asyncSetRoute कॉल करें और जब तक सब कुछ तैयार नहीं हो जाता तब तक यह राउटर को अपडेट करना स्थगित कर देगा।

छद्म कोड और सामान्य प्रकार, लेकिन यह मेरे लिए समग्र दृष्टिकोण की तरह लगता है। शायद प्रतिक्रिया-राउटर को यह प्रदान करना चाहिए, शायद नहीं ... शायद यह आदर्श रूप से बाहरी सहायक के रूप में प्रदान किया जाता है, मुझे यकीन नहीं है।

इसलिए घंटों शोध के बाद, मैं अभी पुष्टि कर रहा हूं कि सर्वर साइड रेंडरिंग _impossible _ है जब तक कि आप सब कुछ ऊपर से नीचे (?) नहीं खिलाते।

संभावित अल्पकालिक समाधान:
ए. स्टोर को पहले से भरें और सर्वर साइड लोडिंग को सिंक्रोनस बनाएं

बी. एसिंक्स द्वारा अपना एक डेटा ऑब्जेक्ट लाने के बाद ऊपर से सब कुछ एक डेटा इनपुट के रूप में फ़ीड करें।

पुन: 'ए'। यह तब तक काम नहीं करेगा जब तक आप पहले से ही नहीं जानते कि आपकी रेंडर संरचना कैसी दिखेगी। मुझे अपने विभिन्न संग्रह/मॉडल/एपीआई निर्भरताओं को जानने के लिए इसे प्रस्तुत करने की आवश्यकता है। साथ ही, मैं क्लाइंट पर एसिंक्स कैसे प्राप्त कर सकता हूं, लेकिन दो अलग-अलग एपीआई के बिना सर्वर पर सिंक कैसे करूं?

पुन: 'बी'। मूल रूप से ऊपर की तरह ही समस्या। क्या लोगों को अपने प्रत्येक मार्ग के साथ जाने के लिए कम निर्भरता वाले JSONs बनाने पड़ रहे हैं?

जब हम रिएक्ट समर्थित समाधान की प्रतीक्षा करते हैं तो क्या कोई अन्य अल्पकालिक समाधान हैं? कोई उपयोगकर्ता भूमि कांटे या प्लगइन्स? https://www.npmjs.com/package/react-async ?

@निकस्टीफन

मुझे समस्या समझ में नहीं आ रही है। :-(

1. फ्लक्स या फ्लक्स जैसे कंटेनर (Alt, Redux, Flummox, आदि) का उपयोग करें जहां स्टोर सिंगलटन नहीं हैं।
2. अपने मार्ग संचालकों पर fetchData जैसे स्थिर तरीकों को परिभाषित करें जो वादे लौटाते हैं।
3. सर्वर पर, घटकों के लिए मार्ग का मिलान करें, उनसे fetchData लें और प्रतिपादन से पहले उनके पूरा होने की प्रतीक्षा करें। यह आपके Flux या Redux स्टोर इंस्टेंस को पहले से भर देगा। ध्यान दें कि स्टोर इंस्टेंस सिंगलटन नहीं है - यह एक विशेष अनुरोध के लिए बाध्य है, इसलिए अनुरोध अलग-थलग रहते हैं।
4. जब वादे तैयार हों, तो उस स्टोर इंस्टेंस के साथ समकालिक रूप से प्रस्तुत करें जिसे आपने अभी-अभी भरा है।

इस दृष्टिकोण का वर्णन करने वाले Redux के लिए यहां एक अच्छा ट्यूटोरियल है: https://medium.com/@bananaoomarang/handcrafting -an-isomorphic-redux-application-with-love-40ada4468af4

@gaearon अगर मैंने आपको भ्रमित किया तो मैं क्षमा चाहता हूं। प्रतिक्रिया के लिए धन्यवाद। आपकी सूची से, ऐसा लगता है कि मैं सर्वर डेटा निर्भरता के समाधान को मानने में सही हूं, केवल अपने मूल घटक (स्थैतिक विधियों/आपके द्वारा लिंक किए गए आलेख) पर डेटा आवश्यकताओं को परिभाषित करना है। यदि आपकी डेटा निर्भरता को रूट पर परिभाषित किया गया है, तो स्टोर आदि को पहले से भरना बहुत आसान है।

यह अच्छा प्रवाह अभ्यास है, लेकिन क्या यह संभावित रूप से सीमित नहीं है? अगर मैं आपके व्यू ट्री के नीचे एक छोटा घटक जोड़ता हूं जिसके लिए कुछ बहुत अलग डेटा की आवश्यकता होती है, तो मुझे रूट पर डेटा निर्भरताओं को संपादित करने की आवश्यकता होती है।

मैं जो मांग रहा हूं वह एसिंक्रोनस डेटा जरूरतों को परिभाषित करने के लिए गहराई से नेस्टेड घटकों का एक तरीका है।

अगर मुझे उनकी ज़रूरतों को रूट कंपोनेंट में जोड़ना है, तो क्या मैं रूट को उस सब कंपोनेंट्स की ज़रूरतों के साथ नहीं जोड़ रहा हूँ?

@NickStefan प्रतिक्रिया-मार्ग के साथ , उदाहरण के लिए, async डेटा प्राप्त करना इस तरह दिखता है:

import Router from 'react-routing/lib/Router';
import http from './core/http';

const router = new Router(on => {
  on('/products', async () => <ProductList />);
  on('/products/:id', async (state) => {
    const data = await http.get(`/api/products/${state.params.id`);
    return data && <Product {...data} />;
  });
});

await router.dispatch('/products/123', component => React.render(component, document.body));

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

मुझे लगता है कि रिएक्ट घटकों का इस तरह से उपयोग करने का इरादा नहीं है, वे अभी भी _controller_-views की तुलना में अधिक विचार हैं। संभवत: रिएक्ट की नींव पर एक पूरी तरह से नए पुस्तकालय का निर्माण करना होगा।

मेरा सपना है कि एक दिन हम Wordpress, Drupal या Modx जैसी किसी प्रतिक्रिया का उपयोग करके एक संपूर्ण CMS लिखने में सक्षम होंगे। लेकिन HTML/PHP स्निपेट के बजाय हम रिएक्ट घटकों से वेबसाइट की रचना करेंगे।

@निकस्टीफन

आपकी सूची से, ऐसा लगता है कि मैं सर्वर डेटा निर्भरता के समाधान को मानने में सही हूं, केवल अपने मूल घटक (स्थैतिक विधियों/आपके द्वारा लिंक किए गए आलेख) पर डेटा आवश्यकताओं को परिभाषित करना है। यदि आपकी डेटा निर्भरता को रूट पर परिभाषित किया गया है, तो स्टोर आदि को पहले से भरना बहुत आसान है।

अगर मुझे उनकी ज़रूरतों को रूट कंपोनेंट में जोड़ना है, तो क्या मैं रूट को उस सब कंपोनेंट्स की ज़रूरतों के साथ नहीं जोड़ रहा हूँ?

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

यह "हर घटक एक निर्भरता की घोषणा कर सकता है" के रूप में दानेदार नहीं है, लेकिन मैंने पाया है कि ज्यादातर मामलों में रूट हैंडलर (शीर्ष और नेस्टेड वाले) तक पहुंचने वाले डेटा को सीमित करना मैं चाहता हूं। मेरे पास नीचे शुद्ध घटक हैं जो props माध्यम से डेटा स्वीकार करते हैं, इसलिए वे यह भी नहीं जानते हैं कि इसे प्राप्त किया जा रहा है। यह समझ में आता है कि वे इसका अनुरोध नहीं कर सकते।

"हर घटक एक निर्भरता की घोषणा कर सकता है" दृष्टिकोण तब तक व्यावहारिक नहीं है जब तक आपके पास किसी प्रकार का अनुरोध बैचिंग समाधान न हो। कल्पना कीजिए कि यदि <User> यह घोषणा करता है कि उसे एक API कॉल की आवश्यकता है, और अब आप 100 <User> s की एक सूची प्रस्तुत करते हैं—क्या आप 100 अनुरोधों की प्रतीक्षा करना चाहेंगे? इस प्रकार का डेटा प्राप्त करने की आवश्यकता ग्रैन्युलैरिटी केवल तभी काम करती है जब आपके पास अनुरोध बैचिंग समाधान हो। अगर वह आपको सूट करता है, तो रिले बिल्कुल वैसा ही है। लेकिन इसके लिए आपको एक विशेष बैकएंड की आवश्यकता होगी।

@NickStefan हम वर्तमान में प्रति-घटक async लाने का समर्थन नहीं करते हैं। हम इसे जोड़ना चाहेंगे। यह मुद्दा हमारी प्रगति को ट्रैक करता है, हालांकि कोई भी इस पर सक्रिय रूप से काम नहीं कर रहा है और इसमें बड़े पुनर्गठन की आवश्यकता होगी इसलिए इसमें कुछ समय लगेगा।

@gaearon

"हर घटक एक निर्भरता की घोषणा कर सकता है" दृष्टिकोण तब तक व्यावहारिक नहीं है जब तक आपके पास किसी प्रकार का अनुरोध बैचिंग समाधान न हो।

इस पर कुछ और विचार करने के बाद, मैं आपकी बात से सहमत हूं। जो मैं चाह रहा था वह वास्तव में व्यावहारिक नहीं है।

मैंने मूल रूप से सोचा था कि आपका 100 . भीउदाहरण टीम अनुशासन के साथ ठीक रहेगा (यानी केवल <UsersContainer> बनाएं जो सभी 100 के लिए 1 अनुरोध करता है)। लेकिन यह केवल एक सम्मेलन करने के लिए "लोग-स्केलेबल" नहीं है। यह शायद रूट या राउटर पर सभी निर्भरताओं को लागू करने के लिए सबसे अच्छा है। यहां तक ​​​​कि रिले प्रकार आपको अपने तीन अलग-अलग कंटेनरों (RelayContainer, RelayRootContainer, RelayRouter आदि) के साथ रूट पर निर्भरता घोषित करने के लिए मजबूर करता है। यह इस बात को साबित करता है कि पेड़ पर आपकी निर्भरता घोषणाओं को अनिवार्य रूप से "लहराने" का एकमात्र तरीका है।

नमस्ते!
क्या इस पर कोई अपडेट है?

+1

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

रिले में भी, आपको मूल रूप से रूट कंटेनर घोषणाओं, रिले कंटेनर इत्यादि के साथ पेड़ पर अपनी निर्भरताओं को "लहराना" पड़ता है। सिंक्रोनस प्रतिपादन जाने का रास्ता है।

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

माना। मुझे लगता था कि हमें इसकी आवश्यकता है, लेकिन वास्तव में यह देखने के लिए पीछे की ओर है कि कौन सा डेटा लोड करना है। दृश्य एप्लिकेशन स्थिति का एक कार्य है, जो स्वयं अनुरोध का एक कार्य है (और संभवतः उपयोगकर्ता की स्थिति, यदि कोई सत्र है)। यही प्रतिक्रिया है; घटकों को यह निर्दिष्ट करने की अनुमति देना कि कौन सा डेटा लोड किया जाना चाहिए "एक तरह से डेटा प्रवाह" विचार, आईएमओ के खिलाफ जाता है।

यह वास्तव में पीछे की ओर है कि दृश्य निर्दिष्ट करें कि कौन सा डेटा लोड करना है।

मुझे पूरा यकीन नहीं है कि यह सच है। कभी-कभी, घटक केवल एक चीज है जो जानता है कि कौन सा डेटा लोड करना है। उदाहरण के लिए, मान लें कि आपके पास एक विस्तार योग्य ट्री व्यू है जो उपयोगकर्ता को नोड्स के विशाल ग्राफ को ब्राउज़ करने की अनुमति देता है - यह पहले से जानना असंभव है कि किस डेटा को लोड करने की आवश्यकता है; केवल घटक ही इसका पता लगा सकता है।

भले ही, यह चर्चा बहुत अधिक प्रासंगिक हो सकती है यदि हम एक वेब कार्यकर्ता (#3092) के भीतर रिएक्ट कोड चलाने के विचार का अनुसरण करते हैं, जहां पुल के पार संचार करने के लिए async की आवश्यकता होती है।

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

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

पूरे सूत्र को नहीं पढ़ा तो क्षमा करें यदि इस पर पहले ही चर्चा हो चुकी है।

एक चीज जो वास्तव में मदद करेगी यदि कोई react-dom/server विधि थी जो एक घटक और अग्नि जीवन चक्र विधियों को "प्रारंभ/तत्काल" करेगी लेकिन डेवलपर को यह तय करने दें कि वह घटक को HTML स्ट्रिंग में प्रस्तुत करने के लिए तैयार है या नहीं . उदाहरण के लिए, डेवलपर async विधियों को पूरा करने के लिए प्रतीक्षा करने के लिए setTimeout या अधिक विश्वसनीय कुछ का उपयोग कर सकता है।

यह "हैक" है जिसे मैं इसे प्राप्त करने के लिए इस समय redux के साथ उपयोग कर रहा हूं:

  // start/instantiate component
  // fires componentWillMount methods which fetch async data
  ReactDOM.renderToString(rootEle)

  // all my async methods increment a `wait` counter 
  // and decrement it when they resolve
  const unsubscribe = store.subscribe(() => {
    const state = store.getState()
    // as a result, when there are no more pending promises, the wait counter is 0
    if (state.wait === 0) {
      unsubscribe()
      // all the data is now in our redux store
      // so we can render the element synchronously
      const html = ReactDOM.renderToString(rootEle)
      res.send(html)
    }
  })

इस दृष्टिकोण के साथ समस्या यह है कि दूसरा ReactDOM.renderToString सभी componentWillMount विधियों को फिर से सक्रिय करता है जिसके परिणामस्वरूप अनावश्यक डेटा प्राप्त होता है।

हे लोगों! क्या इस पर अभी काम किया जा रहा है? मुझे लगता है कि यह मुद्दा महत्व में बढ़ रहा है। मैंने हाल ही में एक पुस्तकालय बनाया है जो प्रतिक्रिया रेडक्स के connect को dataConnect तक विस्तारित करता है जहां आप कंटेनर डेटा आवश्यकताओं को भी निर्दिष्ट कर सकते हैं। फिर इन डेटा आवश्यकताओं को रनटाइम पर बंडल किया जाता है और एक ही अनुरोध में GraphQL के साथ पूछताछ की जाती है। मुझे लगता है कि यह डेटा स्पेसिफिकेशंस का भविष्य है क्योंकि यह कंपोज़ेबिलिटी और आइसोलेशन को बढ़ावा देता है और एक अधिक प्रदर्शनकारी फ़ेचिंग भी सुनिश्चित करता है। (रिले पर देखी गई सभी अवधारणाएं)

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

प्रतिक्रिया तत्वों के पेड़ पर क्रियाओं और अद्यतनों को ट्रिगर करने और मांग पर डीओएम स्ट्रिंग परिणाम प्राप्त करने में सक्षम होना शानदार होगा। यहां बताया गया है कि मैं इसे कैसे चित्रित करता हूं:

const virtualTree = ReactDOM.renderVirtual(rootEle);

// get the bundled query from redux store for example
const bundle = store.getState().bundle;

// Fetch the data according to the bundle
const data = fetchDataSomehow(bundle);

// hydrate store
store.dispatch({type: 'hydrate', data});
// components that should update should be marked on the virtual tree as 'dirty'

virtualTree.update(); // this would only update the components that needed update

const domString = virtualTree.renderToString(); // final result

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

तुम लोग क्या सोचते हो? कुछ विचार करने के लिए या मैं इसे पूरी तरह से गलत देख रहा हूँ?

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

तब से, मैंने REST/HATEOS के पीछे के आदर्शों के लिए बहुत गहरा सम्मान विकसित किया है, क्योंकि बड़े पैमाने पर सादगी जो अनुप्रयोगों की एक प्रणाली (ब्राउज़र, क्रॉलर, एप्लिकेशन सर्वर, प्रॉक्सी, सीडीएन, आदि) में उभरती है, जब इसके मार्गदर्शक सिद्धांत होते हैं। पीछा किया। चूंकि यह इस मुद्दे से संबंधित है, _यूआरएल आवेदन राज्य का एक सही प्रतिनिधित्व होना चाहिए। यह, और केवल इसे, यह निर्धारित करना चाहिए कि अनुरोध को पूरा करने के लिए कौन सी जानकारी की आवश्यकता है। व्यू लेयर, रिएक्ट, इसे निर्धारित नहीं करना चाहिए; इसे डेटा के आधार पर बनाया जाना चाहिए। दृश्य डेटा का एक कार्य है, और डेटा URL का एक कार्य है ।

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

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

उस सारे काम के लिए आपको क्या मिलता है, जो आपके पास नहीं होता?

• एक उपयोगकर्ता के लिए एक यूआरएल साझा करके दूसरे उपयोगकर्ता को उसी स्थान पर लाने की क्षमता जो एप्लिकेशन में है।
• ब्राउज़र द्वारा प्रदान किए जाने वाले सभी टूल का उपयोग करके एप्लिकेशन को नेविगेट करने की क्षमता। मानक ग्राहक इसके तत्व में है।
• जटिल पेजिनेशन को इस तरह से पेश करने की क्षमता जो क्लाइंट के लिए अनुसरण करना आसान है: एक प्रतिक्रिया में next लिंक। एफबी ग्राफ एपीआई इसका एक बेहतरीन उदाहरण है।
• Google Analytics में आपके उपयोगकर्ता के कार्यप्रवाह का विस्तृत ग्राफ़।
• उक्त ग्राफ़ को स्वयं बनाने का विकल्प कुछ भी नहीं बल्कि लॉग का अनुरोध करता है।
• अराजकता के स्टार-रूट से बचना: सभी अनुरोधों को app.get("*", theOneTrueClientonaserverEntryPoint) रूप में मिलान करने के बजाय, आप अपने सर्वर एप्लिकेशन फ्रेमवर्क का उपयोग कर सकते हैं जैसा कि इसका इरादा था। आप 200 OK\n\n{status: "error"} बजाय अनुरोधों से सही HTTP स्थिति कोड वापस कर सकते हैं। तारा मार्ग मोहक है, लेकिन यह पागलपन की ओर ले जाता है।

तो, अब जबकि रिएक्ट, हमारा स्टार टूल, ऑपरेशन को नियंत्रित नहीं कर रहा है, हम अपना डेटा कैसे प्राप्त करें? हम कैसे जानते हैं कि किन घटकों को प्रस्तुत करना है?

1. डेटा एक्सेस फ़ंक्शन पर रूट करें और प्रासंगिक अनुरोध पैरामीटर के लिए डेटा प्राप्त करें। तब तक दोहराएं जब तक आप पूरे यूआरएल को पार्स नहीं कर लेते और एक पूर्ण संदर्भ वस्तु नहीं हो जाती।
2. संदर्भ को सबसे सरल प्रतिक्रिया वस्तु में बदलना संभव है, जैसे कि आप किसी एपीआई अनुरोध का जवाब देने जा रहे थे। क्या आप एक एपीआई अनुरोध की सेवा कर रहे हैं? फिर आपका काम हो गया और DRY।
3. उस न्यूनतम जटिल, लेकिन संभवतः बड़े, शीर्ष स्तर के घटक पर आपत्ति जताएं। यहाँ से, यह प्रतिक्रिया घटक संरचना सभी तरह से नीचे है।
4. स्ट्रिंग को प्रस्तुत करें, प्रतिक्रिया दें। अपने सीडीएन को बताएं कि वह इसे हमेशा के लिए कैश कर सकता है (* जब तक कि आपने ऊपर इस विकल्प का त्याग नहीं किया है), क्योंकि सीडीएन की पहचान यूआरएल से होती है, और आपके सभी राज्यों में एक यूआरएल होता है। ज़रूर, सीडीएन में अनंत भंडारण नहीं है, लेकिन वे प्राथमिकता देते हैं।

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

यही प्रतिक्रिया को महान बनाता है: यह दृश्य है। सबसे अच्छा दृश्य। केवल दृश्य। मैं

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

मैं पुराने ज्ञान के लिए बहुत सम्मान करता हूं, लेकिन यह विकास और नए मानकों के निर्माण की सीमा नहीं होनी चाहिए, कम से कम मैं इसे इस तरह देखता हूं।

मेरा प्रस्ताव मूल रूप से रिएक्ट को नहीं बदलना है, लेकिन डोम/घटकों के पेड़ को बदलने का एक 'वर्चुअल ओनली' तरीका है, मूल रूप से एक रिएक्ट जो सर्वर साइड पर 'रन' हो सकता है, जो मुझे लगता है कि करना बहुत आसान है (बस ब्लॉक एक्शन डोम को बदलने के लिए)। आपके पास अभी भी कैशिंग हो सकती है और सीडीएन मौजूद हो सकता है। साइटों और अनुप्रयोगों की बढ़ती गतिशीलता के साथ आजकल स्थिर कैशिंग कम हो जाएगी लेकिन यह एक और विषय है 😄

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

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

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

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

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

:बियर:

PS मेरा मतलब यह नहीं था कि HTTP एक MMOFPS के लिए एक अच्छा संचार प्रोटोकॉल होगा

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

मेरा मानना ​​है कि अमूर्तता का यह स्तर जाने का रास्ता है। मैं इसे रिलैक्स सीएमएस पर इस्तेमाल कर रहा हूं और वर्कफ़्लो और आइसोलेशन के साथ काम करना एक आनंद है। इतना ही नहीं बल्कि अनुरोध किया गया डेटा अधिक नहीं है, न ही कम है जो यूआई की जरूरत है, और यह स्वचालित रूप से प्रत्येक घटक की आवश्यकता वाले डेटा को एकत्रित करके और इसे विलय करके स्वचालित रूप से बनाया जाता है। यदि आप जाँच करने में रुचि रखते हैं तो यह Relate http://relax.github.io/relate/how-it-works.html द्वारा किया जाता है। इसके साथ मैं अपने आवेदन में कहीं भी किसी भी घटक को शामिल कर सकता हूं और यह सुनिश्चित कर सकता हूं कि यह मेरे आवेदन के एक स्वतंत्र ब्लॉक के रूप में काम करेगा।

सर्वर साइड प्रतिपादन अभी भी पता लगाने के लिए केवल एक चीज है। प्रतिक्रिया के स्रोत कोड के माध्यम से जाने के बाद मेरा मानना ​​​​है कि जैसा कि मैंने वर्णन किया है, पहले से ही एक समाधान हो सकता है, यदि नहीं तो मैं समाधान पर काम कर सकता हूं यदि प्रतिक्रिया टीम का कोई व्यक्ति इससे सहमत है।

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

मेरे लिए, मुख्य प्रश्न यह है कि इस तरह के फ़ंक्शन का निर्माण कैसे किया जाए ।

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

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

मैं क्लाइंट-साइड पर भी रिएक्ट के साथ इस दृष्टिकोण का उपयोग कर रहा हूं और यह बहुत व्यवहार्य लगता है। रिएक्ट घटकों को शुरू से ही _controller-views_ के रूप में दर्शाया गया है और इसी तरह मैं उनका उपयोग करता हूं। मेरे पास मेरे _controller_ घटक हैं जो डेटा लाने के लिए ज़िम्मेदार हैं और फिर मेरे पास मेरे _view_ घटक हैं जो केवल दृश्यों की परवाह करते हैं। संपूर्ण पृष्ठ दोनों प्रकार के घटकों से बना है। वे अच्छी तरह से अलग हो गए हैं और आसानी से पुन: उपयोग करने योग्य हैं।

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

• मुख्य उपकरण प्रतिक्रिया-राउटर है । यह प्रत्येक यूआरएल पर एसिंक्रोनस डेटा अनुरोध को हुक करने की अनुमति देता है और यह क्लाइंट-साइड और सर्वर-साइड दोनों काम करता है। औपचारिक रूप से, यह दृष्टिकोण उस समस्या से ग्रस्त है जिसका मैंने पहले उल्लेख किया था। वे _controller_ घटक संभव नहीं हैं। लेकिन यहां जो मायने रखता है वह है react-router का डिज़ाइन। यह एक ही स्थान पर _डेटा-पदानुक्रम_ और _दृश्य/घटक पदानुक्रम_ दोनों को परिभाषित करने की अनुमति देता है और वास्तविक मार्ग परिभाषाएं भी श्रेणीबद्ध हैं। यह बहुत _React-like_ लगता है।
• पूरे राज्य (डेटा) को redux के साथ नियंत्रित किया जाता है। अन्य सभी लाभों के अलावा, यह पूरे राज्य को एक ही वस्तु में रखता है जिसका अर्थ है कि सर्वर पर ऑब्जेक्ट बनाना और क्लाइंट को भेजना बहुत ही सरल और स्वाभाविक है। इसके अलावा connect() दृष्टिकोण के लिए धन्यवाद, प्रोप का उपयोग करके शीर्ष स्तर से सभी डेटा को पास करना आवश्यक नहीं है (जो कि मेरे आवेदन के वर्तमान आकार को देखते हुए बिल्कुल पागल होगा)।
• पहेली का एक और टुकड़ा पुनर्चयन है जो हमें राज्य को यथासंभव छोटा रखने की अनुमति देता है। और decoupling कारक को भी बहुत बढ़ाता है।

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

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

अभी, मैं सिर्फ आइसोमोफिक प्रतिक्रिया, आईएमओ के लिए इसके बढ़ते महत्व को दूसरा करना चाहता था। मैं इस बीच एक समाधान निकालने की कोशिश करूंगा। धन्यवाद।

@decodeman यदि आप रुचि रखते हैं, तो संबंधित के लिए, मैंने घटकों से डेटा निर्भरता प्राप्त करने के लिए एक न्यूनतम प्रतिक्रिया ट्रैवर्स किया है https://github.com/relax/relate/blob/master/lib/server/get-data -निर्भरता.जे.एस. इस तरह मैं सभी डेटा निर्भरता प्राप्त कर सकता हूं -> डेटा प्राप्त करें -> स्ट्रिंग पर प्रतिक्रिया दें।

@decodeman , FWIW हम एक बड़े प्रोडक्शन ऐप में सफलतापूर्वक डबल रेंडर अप्रोच (जैसे आप क्या कहते हैं) का उपयोग कर रहे हैं। यह इस redux-saga उदाहरण से प्रेरित है, लेकिन सामान्य दृष्टिकोण को किसी भी प्रकार के async लोडिंग के साथ अच्छी तरह से काम करना चाहिए। आपको बस लोडिंग को componentWillMount पर ले जाने की जरूरत है। इसे प्रबंधनीय रखने में मदद करने के लिए, हमारे पास उच्च क्रम के घटक भी हैं जो सामान्य लोडिंग परिदृश्यों का ध्यान रखते हैं (उदाहरण के लिए, प्रोप x और यदि शून्य हो तो लोड करें।

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

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

इसे इसका नाम दिया गया स्ट्रीम चेक आउट रिएक्ट स्ट्रीम हल कर दिया गया है।

गुरुवार, नवंबर 3, 2016 को, फ्लोरियन क्राउथन सूचनाएं @github.com
लिखा था:

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

मुझे लगता है कि इस तरह का एक समाधान हमारे द्वारा उपयोग किए जाने वाले सभी हैकी तरीकों को हल कर देगा
इस समय उचित सर्वर साइड रेंडरिंग के लिए। उदाहरण के लिए अनुमति सहित
प्रतिक्रिया राउटर v4 के साथ प्रतिक्रिया अनुप्रयोगों का आसान सर्वर साइड प्रतिपादन
(जो अब एक केंद्रीकृत मार्ग विन्यास का उपयोग नहीं करता है जो अभी है
आइसोमोर्फिक अनुप्रयोगों को काम करने का एकमात्र तरीका)

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/facebook/react/issues/1739#issuecomment -258198533,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/ATnWLUIEJw4m1Y3A4oGDOBzP6_ajDcqIks5q6g4_gaJpZM4CHAWq
.

@ yamat124 अगर मैं प्रतिक्रिया स्ट्रीम की खोज करता हूं तो मुझे केवल यह प्रोजेक्ट मिलता है: https://github.com/aickin/react-dom-stream

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

https://github.com/makeomatic/redux-connect के बारे में क्या

फिर से वे सभी बहुत हैकी तरीके हैं। इसे घटक वृक्ष से स्वतंत्र होने के लिए रूटिंग की आवश्यकता होती है। और मार्ग में शामिल "मुख्य" घटक को उन सभी डेटा को जानना होगा जिन्हें लोड करने की आवश्यकता है (समय का 99% काम करता है लेकिन हमेशा नहीं)। प्रतिक्रिया में विलंबित घटक रेंडर होने पर दोनों अप्रचलित हो जाएंगे।

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

Next.js के पास सर्वर-साइड रेंडरिंग करने के लिए async getInitialProps है, दुर्भाग्य से अभी भी माता-पिता से बच्चे के getInitialProps को वापस रूट पर कॉल करने की आवश्यकता है। अपोलो ग्राफक्यूएल क्लाइंट सर्वर-साइड डेटा आवश्यकताओं को इकट्ठा करने के लिए सभी पेड़ों को पार करने की अनुमति देता है और फिर सब कुछ वापस भेज देता है। नेक्स्ट + अपोलो का उदाहरण: https://github.com/sedubois/realate।

इन चीजों को एक साथ मिलाने के लिए async रिएक्ट घटक जीवनचक्र विधियों का होना बहुत अच्छा होगा।

इस सप्ताह एसएसआर के बारे में अभी सीखा, आशा है कि मैं जो लिख रहा हूं वह समझ में आता है 😄

/सीसी @nkzawa @stubailo

BTW componentWill/DidMount पहले से ही async हैं, क्या इससे मदद मिलती है?

https://twitter.com/Vjeux/status/772202716479139840

@sedubois क्या रिएक्ट प्रतिपादन से पहले हल करने के वादे की प्रतीक्षा करता है? अन्यथा, वास्तव में मदद नहीं करता है!

@olalonde ऐसा लगता है: https://github.com/sedubois/react-async-poc/blob/1d41b6f77e789c4e0e9623ba1c54f5ed8d6b9912/src/App.js

const getMessage = async () => new Promise((resolve) => {
  setTimeout(() => {
    resolve('Got async message!');
  }, 3000);
});
class App extends Component {
  state = {
    message: 'Loading...',
  };
  async componentWillMount() {
    this.setState({ message: await getMessage() });
  }
  render() {
    return (... {this.state.message} ...);
  }
}

@sedubois ध्यान दें कि, आपके उदाहरण में, componentWillMount

  async componentWillMount() {
    this.setState({ message: await getMessage() });
  }

undefined और एक वादा लौटाता है, लेकिन स्क्रीनशॉट से पता चलता है कि रिएक्ट वादे के लिए इंतजार नहीं करता (यह नहीं कर सकता) , क्योंकि यह Loading... टेक्स्ट को प्रस्तुत करता है।

संपादित करें: सही किया गया।

@sedubois @polytypic यह फ़ंक्शन के भीतर फेंकी गई सभी त्रुटियों को चुपचाप अनदेखा कर देगा, क्योंकि वादा बिल्कुल भी संभाला नहीं जाता है।

@polytypic @dantman मुझे पूरा यकीन नहीं है कि "वादे को बिल्कुल भी संभाला नहीं गया" का क्या अर्थ है। यह await ऑपरेटर द्वारा प्रतीक्षित है। आपको त्रुटि को पकड़ने की कोशिश करने की ज़रूरत है, मैंने उदाहरण अपडेट किया है (अपोलो के समान लोडिंग/त्रुटि हस्ताक्षर का उपयोग करके)।

    try {
      this.setState({ message: await getMessage() });
    } catch(error) {
      this.setState({ error });
    }

और प्रस्तुत करना:

{error ? error : loading ? 'Loading...' : message}

@sedubois जब आप async एक फ़ंक्शन यह निहित रूप से एक वादा देता है, तो फ़ंक्शन में कोई भी throw स्टैक को फेंकने के बजाय उस वादे की अस्वीकृति में बदल जाता है। इसका मतलब है कि componentWillMount अब अपने कॉलर को एक वादा लौटा रहा है।

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

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

और यहां तक ​​कि कोशिश करने..कैच करने से भी आप इससे पूरी तरह से सुरक्षित नहीं होंगे। यदि setState आपके कैच से कोई त्रुटि फेंकता है या आप कैच में एक टाइपो बनाते हैं, तो वह त्रुटि चुपचाप गायब हो जाएगी और आपको पता नहीं चलेगा कि कुछ टूट गया है।

@sedubois दरअसल, एक

फिर भी, स्क्रीनशॉट स्पष्ट रूप से दिखाते हैं कि रिएक्ट वादे के हल होने की प्रतीक्षा नहीं करता है। यह render पर कॉल करने के तुरंत बाद componentWillMount पर कॉल करता है और Loading... टेक्स्ट प्रस्तुत करता है। फिर यह render पर कॉल करने के बाद फिर से setState कॉल करता है। यदि रिएक्ट ने वादे को हल करने के लिए प्रतीक्षा की तो यह Loading... टेक्स्ट को बिल्कुल भी प्रस्तुत नहीं करेगा। इसके बजाय, यह तब तक प्रतीक्षा करेगा जब तक कि वादा हल नहीं हो जाता है और उसके बाद ही कॉल करेगा render , जो कि इस तरह के व्यवहार के बारे में है: सर्वर साइड रेंडरिंग के दौरान async IO करने में सक्षम होने के लिए।

@dantman @polytypic धन्यवाद हां, प्रतिक्रिया के लिए प्रतीक्षा करने और त्रुटियों को ठीक से संभालने के लिए रिएक्ट के अंदर निश्चित परिवर्तनों की आवश्यकता है। हो सकता है कि इसके कोड में कुछ await यहां और वहां जोड़कर यह कर सके

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

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

@sedubois इसे विधियों का एक अलग ढेर होना होगा; या एक तोड़ने वाला परिवर्तन। रिएक्ट की वर्तमान रेंडर विधियाँ सिंक हैं, इसलिए हमें एक अलग सर्वर रेंडर विधि की आवश्यकता होगी जो एक वादा लौटाए।

@dantman मैं यहां कोई राय नहीं देना चाहता क्योंकि ये पानी मेरे लिए बहुत गहरा है (मेरा प्रारंभिक उद्देश्य केवल Vjeux के async घटक WillMount हैक को इंगित करना था ...), लेकिन हम्म, प्रतिक्रिया नहीं कर सकता के प्रकार पर नज़र डालें जीवन चक्र विधियों द्वारा लौटाई गई वस्तु और यदि यह एक वादा है, तो इसे एसिंक्स को संभालें और अन्यथा इसे सिंक करें (जैसे वर्तमान में, यानी पीछे की ओर संगत तरीके से)?

मुझे वह पसंद है जो @fkrautan ने प्रस्तावित किया था। एक जीवनचक्र विधि load जो एक वादा या undefined और एक अतिरिक्त async renderToStringAsync फ़ंक्शन वापस कर सकती है। लेकिन क्लाइंट और सर्वर पर load हमेशा कॉल किया जाना चाहिए। यदि हम render या renderToString करते हैं तो लौटाए गए वादे को आज के व्यवहार से मेल खाने के लिए अनदेखा कर दिया जाता है। यदि हम renderToStringAsync और load एक वादा लौटाता है, तो वादे को प्रस्तुत करने से पहले हल किया जाना चाहिए।

Next.js को पसंद क्यों नहीं करते, एक प्रतिक्रिया async getInitialProps जीवनचक्र फ़ंक्शन जोड़ें जिसे कंस्ट्रक्टर से पहले बुलाया जाता है? यदि ऐसी कोई विधि नहीं है, तो सीधे कंस्ट्रक्टर को कॉल करें।

const props = await (Component.getInitialProps ? Component.getInitialProps(ctx) : {});
...
const app = createElement(App, {
  Component,
  props,
  ...
});

ऐसा लगता है कि Next.js काम करने का प्रबंधन करता है, सिवाय इसके कि इसका getInitialProps रिएक्ट घटक जीवनचक्र से जुड़ा नहीं है, इसलिए इसे केवल शीर्ष-स्तरीय घटक पर ही बुलाया जा सकता है। तो विचार हैं और बस एक साथ जुड़ सकते हैं?

@sedubois मुझे नहीं लगता कि getInitialProps सही जगह है। सबसे पहले जो लोग ES6 का उपयोग कर रहे हैं, उनके पास उस पद्धति का उपयोग नहीं है। दूसरा, आप इनिटलप्रॉप्स पर काम नहीं करना चाहते हैं (जो कि सिर्फ डिफॉल्ट हैं) आप इनिटलप्रॉप्स के मर्ज के ऊपर काम करना चाहते हैं + प्रॉप्स में पास। इसलिए एक नई जीवनचक्र घटना के बारे में मेरा सुझाव है जो componentWillMount से पहले भेजी जाती है।

मुझे लगता है कि @ Lenne231 विचार कुछ समस्याएं पैदा कर सकता है क्योंकि लोग उस वादे के लिए अन्य जीवनचक्र की घटनाओं को पहले ही हल कर सकते हैं। अब एक ही जीवनचक्र घटना के दो अलग-अलग व्यवहार होने से यह थोड़ा मुश्किल हो जाता है।

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

जो लोग ES6 का उपयोग कर रहे हैं, उनके पास उस पद्धति का उपयोग नहीं है

@fkrauthan शायद आप getInitialState संदर्भ लें? यहां मैं एक नए की बात कर रहा था, getInitialProps (नाम नेक्स्ट.जेएस में इस्तेमाल किया गया)।

आपके दूसरे बिंदु के लिए, हाँ यह बेहतर हो सकता है कि नई जीवनचक्र विधि componentWillMount से पहले की बजाय constructor से पहले हो। मुझे लगता है कि नेक्स्ट में ऐसा नहीं है क्योंकि उनके पास रिएक्ट जीवनचक्र को बदलने की सुविधा नहीं है जैसा कि पहले उल्लेख किया गया है। इसलिए उन विचारों को रिएक्ट के भीतर लाना बहुत अच्छा होगा।

@sedubois वह भी। मैं उदाहरण के लिए es7 फीचर का उपयोग करता हूं और static props = {}; अपने क्लास बॉडी में परिभाषित करता हूं। यह मेरी राय में कोड को पढ़ने के लिए अच्छा बनाता है और मुझे यकीन है कि जैसे ही es7 आधिकारिक रूप से जारी होगा, अधिक से अधिक लोग उस पर स्विच करने जा रहे हैं।

नोट: वर्ग गुण एक "ES7" सुविधा नहीं हैं क्योंकि ES7 को पहले ही अंतिम रूप दिया जा चुका है और केवल नई भाषा सुविधा घातांक ऑपरेटर है। आप जो बात कर रहे हैं वह चरण 2 वर्ग गुण प्रस्ताव है । यह अभी तक भाषा का हिस्सा नहीं है और बदल सकता है या गिरा सकता है।

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

मैंने पहले उल्लेख किया है लेकिन एक अच्छा एपीआई निम्न जैसा कुछ होगा (जो मैंने पहले सुझाव दिया है उसके साथ थोड़ा अपडेट के साथ):

const virtualTree = ReactDOM.renderVirtual(rootEle);

// get the bundled query from redux store for example
const bundle = store.getState().bundle;

// Fetch the data according to the bundle
const data = await fetchDataSomehow(bundle);

// hydrate store (this will set updates on the virtual tree)
store.dispatch({type: 'hydrate', data});

// final result
const domString = virtualTree.renderToString();

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

@ bruno12mota मैं आपकी बात

@fkrauthan हाँ, लेकिन वर्चुअल renderToString को बेहतर बनाने के लिए कुछ प्रयोग किए गए हैं, लेकिन प्रतिक्रिया टीम द्वारा इस मामले पर कोई वास्तविक प्रगति नहीं हुई है (यहां आलोचना नहीं, वे एक अद्भुत काम करते हैं)।

मैं @bruno12mota से सहमत हूं, इस मुद्दे पर कुछ समय से विचार-विमर्श करने के बाद, यह सबसे सरल तरीका है। यह डेवलपर को यह निर्धारित करने की स्वतंत्रता छोड़ देता है कि उनका रेंडर कब "फ्लश" होना चाहिए।

यह सब कुछ बहुत अधिक जटिल बनाता है।

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

मैं @bruno12mota के

उदाहरण के लिए, एक उच्च स्तरीय समाधान एक "उच्च स्तरीय घटक" हो सकता है जो async componentWillMount विधियों को लपेटता है, सभी लंबित वादों की प्रतीक्षा करता है और सब कुछ हल होने पर VDom.renderToString() है। मैं अपने ऐप में एसएसआर के लिए इस तरह की रणनीति का उपयोग कर रहा हूं, हालांकि दुर्भाग्य से मैं अभी बहुत अधिक लाने का काम करता हूं क्योंकि कोई वीडीओएम नहीं है।

मुझे लगता है कि सबसे अच्छा तरीका यह होगा कि वर्तमान में हमारे पास मौजूद किसी भी कार्य को न बदलें। जिसका अर्थ है getInitialState,ComponentWillMount, या renderToString अलग तरीके से व्यवहार नहीं करना।

इसके बजाय, हमें यहां चर्चा की गई समस्या को हल करने के लिए नए फ़ंक्शन जोड़ने चाहिए। जैसे ऐसे फ़ंक्शन हैं जो केवल क्लाइंट पर कॉल किए जाते हैं, ऐसे फ़ंक्शन भी हो सकते हैं जिन्हें केवल सर्वर पर ही कॉल किया जाता है।

मुझे लगता है कि हम प्रतिक्रिया-डोम/सर्वर में "renderToStringAsync" फ़ंक्शन जोड़ सकते हैं। सामान्य रेंडरटॉस्ट्रिंग में अंतर यह होगा कि यह एक वादा लौटाता है।

कार्यान्वयन पक्ष पर, केवल अंतर यह होगा कि एसिंक संस्करण, जब भी यह एक घटक उदाहरण बनाता है, कॉल करें और पहले "प्रारंभ करें ()" का इंतजार करें, इससे पहले कि वह रेंडर () को कॉल करे। यदि घटक में "प्रारंभिक" विधि नहीं है, तो यह तुरंत रेंडर() को कॉल कर सकता है।

तो अगर हमारे पास निम्न उदाहरण ऐप संरचना है:

    ComponentB
    ComponentC
        ComponentD
        ComponentE

प्रक्रिया होगी:

1) instanciate componentA
2) await componentA.initialize();
3) componentA.render()
4) do in parallel(
    instanciate componentB, await componentB.initialize(), componentB.render()
    instanciate componentC, await componentC.initialize(), componentC.render(), do in parallel(
        instanciate componentD, await componentD.initialize(), componentD.render()
        instanciate componentE, await componentE.initialize(), componentE.render()
    )
)
5) render to string

तो, मूल रूप से, हमें बस एक नए फ़ंक्शन "renderToStringAsync" की आवश्यकता है जो एक नए, वैकल्पिक फ़ंक्शन "इनिशियलाइज़" का उपयोग करता है। यह इतना कठिन नहीं होगा।

@VanCoding का वही विचार है जिसके बारे में मैं कुछ समय से सोच रहा था। मैं सोच रहा था कि क्लाइंट पर कंपोनेंटडिडमाउंट में इनिशियलाइज़ को स्वचालित रूप से भी कहा जा सकता है या नहीं?

तो सर्वर पर यह होगा:

initialize()
render()

और ग्राहक पर यह होगा:

render() // without data (unless available synchronously)
componentDidMount()
initialize()
render() // with data

मेरे पास प्रतिक्रिया-राउटर v4 के साथ प्रतिक्रिया सर्वर प्रतिपादन का एक कार्यशील कार्यान्वयन है, और प्रतिक्रिया-अपोलो ग्राफ़कॉल के साथ है।

यह सर्वर-साइड-रेंडरिंग-कोड-स्प्लिटिंग-एंड-हॉट-रीलोडिंग-विद-रिएक्शन-राउटर से प्रेरित था।

मूल रूप से सर्वर रेंडरिंग सिंक्रोनाइज़्ड कंपोनेंट का उपयोग करता है, क्लाइंट रेंडरिंग एसिंक्रोनाइज़्ड कंपोनेंट का उपयोग करता है ताकि वेबपैक एसिंक्स लोड हो रहा हो और मॉड्यूल जावास्क्रिप्ट को निष्पादित कर सके।

वैसे सर्वर रेंडरिंग को नैशॉर्न स्क्रिप्ट इंजन (JVM) के साथ लागू किया जाता है।

• https://github.com/shendepu/moqui-react-ssr
• https://github.com/shendepu/moqui-react-ssr-demo
• https://github.com/shendepu/react-ssr-starter-kit (शाखा अपोलो)

क्लाइंट रेंडरिंग कोड
https://github.com/shendepu/react-ssr-starter-kit/blob/apollo/src/main.js#L63 -L82

सर्वर प्रतिपादन कोड
https://github.com/shendepu/react-ssr-starter-kit/blob/apollo/src/main.js#L128 -L155

मार्ग में सिंक्रनाइज़ या अतुल्यकालिक घटक को अलग करने के लिए एक महत्वपूर्ण स्थान है।
मार्ग में तुल्यकालित घटक
https://github.com/shendepu/react-ssr-starter-kit/blob/apollo/src/routes/Counter/Route.js#L10

RouteAsync में अतुल्यकालिक घटक
https://github.com/shendepu/react-ssr-starter-kit/blob/apollo/src/routes/Counter/RouteAsync.js#L7 -L23

नोट किया गया: फ़ाइल का नाम रूट.जेएस या रूटएसिंक.जेएस होना चाहिए। कोड को हमेशा RouteAsync.js आयात करना चाहिए। वेबपैक इसे रूट.जेएस से बदल देगा यदि इसे सर्वर रेंडरिंग के लिए बनाया गया है।
https://github.com/shendepu/react-ssr-starter-kit/blob/apollo/build/webpack.config.js#L72 -L80

तो बिल्ड dist और dist_ssr दो संस्करण होंगे, dist क्लाइंट के लिए है जबकि dist_ssr सर्वर के लिए है जिसमें केवल दो भाग हैं: विक्रेता और ऐप . स्टोर की स्थिति को index.html के <script> में __INITIAL_STATE__ रूप में निर्यात और एम्बेड किया जाता है। बिल्ड के दो संस्करण होने का कारण ReactDomServer.renderToString() है जो अभी तक async घटक का समर्थन नहीं करता है।

दो-संस्करण-निर्माण दृष्टिकोण के साथ एकमात्र मुद्दा यह है कि देव मोड में चेतावनी है:
React attempted to reuse markup in a container but the checksum was invalid. This generally means that you are using server rendering and the markup generated on the server was not what the client was expecting. React injected new markup to compensate which works but you have lost many of the benefits of server rendering. Instead, figure out why the markup being generated is different on the client or server:

लेकिन चूंकि क्लाइंट और सर्वर संस्करण के बीच केवल अंतर रूट.जेएस और रूटएसिंक.जेएस है, इसलिए चेतावनी को अनदेखा किया जा सकता है, चेतावनी उत्पादन मोड में नहीं दिखाई देती है।

सर्वर साइड पर कंपोनेंट रेंडरिंग से पहले एसिंक्स डेटा लाने के लिए:

• बाकी एपीआई: घटक उपयोग में स्थिर लोडडेटा जोड़ा गया

const { matchedRoutes, params } = matchRoutesToLocation(rootRoute.routes, 
                                                        location, [], {}, rootRoute.pattern)
matchedRoutes.filter(route => route.component.loadData).map(route =>
              route.component.loadData(store, params))

जांच और निष्पादित करने के लिए loadData । मिलान मार्ग मिलान किए गए मार्गों की एक सरणी है जो माता-पिता इंडेक्स 0 । loadData क्रम में या समानांतर में निष्पादित किया जा सकता है।

• GraphQL क्वेरी: सभी GraphQL क्वेरी को निष्पादित करने के लिए बस getDataFromTree से react-apollo/server करें।

BTW: नैशॉर्न स्क्रिप्ट इंजन का उपयोग करने से एक प्रदर्शन अनुकूलन अवसर होता है: चूंकि विक्रेता में लाइब्रेरी कोड और पॉलीफ़िल होते हैं जिन्हें एक बार निष्पादित किया जाता है और पुन: उपयोग किया जाता है, इसलिए बाद के अनुरोधों के लिए, केवल ऐप चंक निष्पादित किया जाता है। चूंकि पुस्तकालयों को वेंडर चंक में ले जाया जाता है, ऐप में src में केवल जावास्क्रिप्ट कोड होता है जो छोटा होता है, इसलिए यह हर बार वेंडर चंक के मूल्यांकन की तुलना में प्रदर्शन को बढ़ावा देता है। (सभी जावास्क्रिप्ट को एक बार संकलित किया जाता है और कैश किया जाता है, प्रत्येक अनुरोध के लिए निष्पादित किया जाता है।)

मैंने झूठ बोला था कि ऐप चंक में केवल src कोड होता है। यह भी शामिल है babel-runtime और दोहराया core-js/library द्वारा संदर्भित babel-runtime । babel-runtime को वेंडर चंक में नहीं ले जाया जा सकता क्योंकि इसमें कोई index.js या मुख्य प्रविष्टि नहीं है ताकि वेबपैक इसे एक मॉड्यूल के रूप में पहचान न सके। लेकिन कोड का आकार छोटा है।

आइए आगे @VanCoding के उदाहरण को विस्तृत करें :

हो सकता है कि इनिशियलाइज़ एक अच्छा नाम नहीं है - नाम को यह स्पष्ट करना चाहिए कि इसका उपयोग केवल सर्वर पर किया जाना है, या ऐसे वातावरण में जहां प्रतिपादन में देरी हो रही है जब तक कि यह फ़ंक्शन वापस नहीं आता - उर्फ ​​क्लाइंट में नहीं। उपाय: getStaticProps , getServerProps , getInitialProps , getAsyncProps ...

इसके अलावा कोर टीम से यह सुनना अच्छा होगा कि क्या ऐसी रेंडरटॉस्ट्रिंगएसिंक विधि विकसित करने में तकनीकी या अन्यथा बाधाएं हैं।

@nmaro ठीक है, मुझे लगता है कि फ़ंक्शन को कुछ भी वापस नहीं करना चाहिए, इसलिए मैं ऐसा नाम पसंद करूंगा जो "प्राप्त करें" से शुरू न हो, लेकिन इसके अलावा, मुझे अभी भी लगता है कि यह सबसे अच्छा तरीका होगा। मुझे कोई फर्क नहीं पड़ता कि इसे अंत में कैसे कहा जाता है।

इसके अलावा, मैंने कोड की लगभग 40 पंक्तियों में इसके लिए अवधारणा का प्रमाण किया

इसलिए, यदि प्रतिक्रिया टीम अभी भी ऐसा नहीं चाहती है, तो इसे किसी तृतीय पक्ष पुस्तकालय में करना इतना कठिन नहीं होगा।

वैकल्पिक रूप से हम रेंडर करने के लिए एक विकल्प जोड़ सकते हैं, जैसा कि in
renderToString(Component, {async: true})

@nmaro जो प्रदान किए गए विकल्पों पर निर्भर फ़ंक्शन का रिटर्न प्रकार बना देगा, जिसे मैं अच्छा अभ्यास नहीं मानता। मुझे लगता है कि एक समारोह को हमेशा एक ही प्रकार का परिणाम वापस करना चाहिए।

@VanCoding क्या आपके पास एक उदाहरण है कि अपने कोड का उपयोग किसी तृतीय-पक्ष lib

@ वैनकोडिंग कूल! लेकिन ईमानदारी से, मुझे लगता है कि प्रतिक्रिया के आंतरिक प्रतिपादन एल्गोरिदम में इसे एकीकृत करना मुश्किल होगा। https://github.com/facebook/react/blob/master/src/renderers/dom/stack/server/ReactServerRendering.js देखें और रिएक्ट के इंटर्नल में खो

@sedubois आप फ़ंक्शन का उपयोग कर सकते हैं जैसे आप सामान्य रेंडरटॉस्ट्रिंग फ़ंक्शन का उपयोग करेंगे। लेकिन यह एक वादा लौटाता है जो सीधे एक स्ट्रिंग को वापस करने के बजाय एक स्ट्रिंग को हल करता है।

तो इसका उपयोग करना ऐसा दिखेगा:

var react = require("react");
var renderAsync = require("react-render-async");
var MyComponent = require("./MyComponent");

renderAsync(react.createElement(MyComponent,{some:"props"}).then(function(html){
    console.log(html);
});

सिद्धांत रूप में, यह किसी भी मौजूदा प्रतिक्रिया घटक को उसी तरह प्रस्तुत करने में सक्षम होना चाहिए जैसे सामान्य रेंडरटॉस्ट्रिंग करता है। अंतर केवल इतना है कि async घटक भी समर्थित हैं।

@nmaro तुम सही हो। यह मददगार होगा।

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

@firasdib हम अभी भी कुछ प्रतिक्रिया

+1

Google अनुक्रमण समस्याओं के लिए SSR की आवश्यकता होती है और नीचे वर्णित सभी सामान हमारे लिए निपटने के लिए हैं और इस प्रकार प्रतिक्रिया के लिए एक सामान्य पुस्तकालय के रूप में सफल होने के लिए यह मुद्दा बहुत महत्वपूर्ण है।

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

हालांकि, जैसा कि मैं समझता हूं कि रिएक्ट देवों ने कंपोनेंटविलमाउंट की उपयोगिता में संदेह दिखाया है और कंस्ट्रक्टर को सभी काम करने की सिफारिश की है। किसी भी तरह काम करेगा।

कुछ लोगों ने तर्क दिया है कि घटकों को शुद्ध विचार बनाने से समस्या का समाधान होता है। वे आंशिक रूप से सही हैं। दुर्भाग्य से, यह सबसे सामान्य मामले में काम नहीं करता है जहां हम नहीं जानते कि रेंडर ट्री होने तक कौन सा डेटा लोड करना है।

इस मुद्दे का मूल यह है कि रेंडर फ़ंक्शन में यह चुनने के लिए तर्क हो सकता है कि DOMTree में कौन से घटक जोड़ना है। यही कारण है कि रिएक्ट इतना शक्तिशाली है और सर्वर साइड रेंडरिंग के लिए इतनी बुरी तरह से अनुकूल है।

IMO का सही समाधान प्रतिक्रिया के साथ सभी जारी किए गए डेटा लोडिंग वादों को पंजीकृत करने में सक्षम होना है। एक बार सभी डेटा लोडिंग वादे पूर्ण प्रतिक्रिया हमें रेंडर परिणाम के साथ वापस बुलाते हैं। इसके कई निहितार्थ हैं:

• डोमट्री कई बार प्रस्तुत किया जाएगा। यह एक लाइव सिस्टम की तरह है जो अस्थिर डेटा लोडिंग स्थिति से स्थिर "लोड" स्थिति में "व्यवस्थित" होता है।
• एक जोखिम है कि सिस्टम बग्गी सिस्टम में स्थिर "लोडेड" स्थिति में नहीं पहुंचेगा। इससे निपटने के लिए टाइम आउट का परिचय देना होगा।

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

इस प्रकार, मैं अभी भी एक कामकाज के बारे में सोच रहा हूं जो सामान्य मामले को काम करने के पक्ष में समझौता करेगा :)

एक बीच में हमें एसएसआर को एसिंक डेटा लोडिंग वातावरण में हल करना होगा।

1. डेटा लोडिंग कॉल को अनुरोध URL से प्राप्त किया जाना है (प्रतिक्रिया-राउटर एक उदाहरण है)। सभी डेटा लोडिंग वादों को वादों की एक सूची में एकत्रित करें।
2. Promise.all() का प्रयोग करें, जो अपने आप में एक वादा है। जब यह वादा सर्वर रेंडरिंग फंक्शन में लोड किए गए डेटा को पूरा करता है।

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

इस मॉडल में समस्या ऊपर # 1 आइटम है। एक साधारण एप्लिकेशन सभी डेटा लोडिंग कॉल को जानता है। स्वतंत्र "मॉड्यूल" के साथ एक जटिल अनुप्रयोग में इस मॉडल को मूल प्रतिक्रिया घटक पेड़ की किसी प्रकार की प्रतिकृति की आवश्यकता होती है और यहां तक ​​​​कि तर्क प्रस्तुत करना भी आवश्यक है।

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

आइटम # 1 कार्यान्वयन अस्पष्ट है। प्रतिक्रिया-राउटर उदाहरण में हमें उस मार्ग से संबंधित शीर्ष स्तर के घटकों को वापस करने के लिए राउटर के रूप में होना चाहिए। मुझे लगता है कि हम इन घटकों को तुरंत चालू कर सकते हैं:

app.use(function(req, res, next) {
    match({ routes, location: req.url }, (error, redirectLocation, renderProps: any) => {
    if (error) {
        res.status(500).send(error.message)
    } else if (redirectLocation) {
        res.redirect(302, redirectLocation.pathname + redirectLocation.search)
    } else if (renderProps) {
        // You can also check renderProps.components or renderProps.routes for
        // your "not found" component or route respectively, and send a 404 as
        // below, if you're using a catch-all route.
        console.log("renderProps", renderProps)
        for (let eachComp of renderProps.components) {
            // create an instance of component
            // ask component to load its data
            // store data loading promise in a collection
            console.log("eachComp: ", eachComp)
        }
        res.status(200).send(renderToString(<RouterContext {...renderProps} />))
        } else {
        res.status(404).send('Not found')
        }
    })
});

तो, शीर्ष स्तर के घटक अब "शुद्ध" घटक नहीं हैं। डेटा लोडिंग को ट्रिगर करने की क्षमता के कारण, ये घटक अब शीर्ष स्तर के नियंत्रक की भूमिका निभाते हैं। फ्लक्स मॉडल इसे बेहतर नहीं बनाता है। यह बस डेटा लोडिंग फ़ंक्शन एसोसिएशन को एक अलग मॉड्यूल में ले जाता है।

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

मैं यही देखता हूं।

अगर मुझे इन SSR निहितार्थों का एहसास हुआ, तो मैंने Google अनुक्रमण योग्य अनुप्रयोगों के लिए React की उपयोगिता के बारे में दो बार सोचा होगा। शायद फ्लक्स एक समाधान है, लेकिन फ्लक्स एक साधारण रिएक्ट एप्लिकेशन की तुलना में एप्लिकेशन को पूरे स्तर पर अधिक जटिल बना देता है। मैं वहाँ गया था। साधारण डेटा लोडिंग फ़ंक्शन के बजाय मुझे कई फाइलों में अपने तर्क का पीछा करना होगा। सैद्धांतिक स्तर पर यह वास्तव में बहुत अच्छा लग रहा था जब तक कि मेरे पास कोई प्रोजेक्ट नहीं चल रहा था। नए लोगों को शुरुआत करने में मुश्किल हुई। Redux को कोड बेस से बाहर निकालने के बाद ऐसी कोई समस्या नहीं है। मुझे लगा कि यह सभी UI डिज़ाइन जटिलताओं का उत्तर है :)

इस हफ्ते के रिएक्ट कॉन्फ से , रिएक्ट फाइबर (रिएक्ट 16) के बाहर होने के बाद, वे निम्नलिखित पर काम करने की योजना बना रहे हैं (माना जाता है कि रिएक्ट 17 के लिए):

इसका मतलब है कि async रिएक्ट जीवनचक्र के तरीके आ सकते हैं?

खैर, फाइबर सामान ज्यादातर तेज/चिकनी री- रेंडरिंग के बारे में नहीं है? सर्वर पर, हम केवल एक बार रेंडर करते हैं, इसलिए मुझे यकीन नहीं है कि उन परिवर्तनों का सर्वरसाइड रेंडरिंग पर कोई प्रभाव पड़ेगा या नहीं।

@VanCoding ने मेरे उपरोक्त संदेश को अपडेट किया जो थोड़ा अस्पष्ट था। मेरा मतलब था कि फाइबर बाहर होने के

मेरे जैसे यहां उतरने वाले लोगों के लिए, मैंने प्रतिक्रिया का उपयोग करके एक कस्टम कार्यान्वयन तैयार किया जो मदद कर सकता है।

https://github.com/siddharthkp/reaqt

कुंजी asyncComponentWillMount है जो केवल सर्वर पर चलती है। यह केवल प्रवेश बिंदु घटकों के लिए उपलब्ध है, सभी घटकों को यहां उल्लिखित मुद्दों से बचने के लिए नहीं।

@siddharthkp मैं वास्तव में नहीं देखता कि आपका घटक क्या हल करने का प्रयास करता है? यदि यह केवल शीर्ष स्तर के अनुप्रयोग प्रतिक्रिया घटक के लिए asyncComponentWillMount का समर्थन करता है तो मुझे आपकी लाइब्रेरी का उपयोग क्यों करना चाहिए? मैं बस उस वादे को बाहर हल कर सकता था और फिर रेंडर को कॉल कर सकता था? या किसी को याद किया था?

@fkrauthan

मैं बस उस वादे को बाहर हल कर सकता था और फिर रेंडर को कॉल कर सकता था?

तुम सही हो, ठीक यही करता है।

अपील यह है कि आपको एक कमांड के साथ async ssr (+ कोड स्प्लिटिंग + hmr) मिलता है। मैंने देखा कि बहुत से लोग ssr को लागू नहीं कर रहे हैं क्योंकि यह बहुत आसान नहीं है, और यही प्रेरणा थी।

यह केवल शीर्ष स्तर के अनुप्रयोग प्रतिक्रिया घटक के लिए asyncComponentWillMount का समर्थन करता है

1. एक आवेदन घटक के लिए नहीं है। आप प्रत्येक पृष्ठ/स्क्रीन/प्रवेश बिंदु के लिए डेटा प्राप्त कर सकते हैं। ( यहां कई प्रवेश बिंदुओं को बढ़ावा देना)

2. पैटर्न जानबूझकर है, अगर पेड़ में प्रत्येक घटक अपना डेटा चाहता है, तो हम प्रदर्शन के लिए खराब पैटर्न को प्रोत्साहित कर सकते हैं। शीर्ष स्तर के घटक पर डेटा प्राप्त करना और इसे बच्चों को प्रॉप्स के रूप में पास करना इसे रोक कर रखता है।

@सिद्धार्थकप नेक्स्ट.जेएस (जिसे रिएक्ट कॉन्फ बीटीडब्ल्यू में भी प्रस्तुत किया गया था) पर आपका रेपो कैसे बेहतर होता है?

https://github.com/zeit/next.js

वैसे भी तीसरे पक्ष के पुस्तकालयों के बारे में चर्चा आईएमएचओ ऑफ-विषय है, जो हम रुचि रखते हैं वह प्रतिक्रिया के भीतर ही समर्थन है।

तीसरे पक्ष के पुस्तकालयों के बारे में चर्चा आईएमएचओ ऑफ-विषय है, हम जिस चीज में रुचि रखते हैं वह रिएक्ट के भीतर ही समर्थन है।

मैं पूरी तरह से सहमत हुँ। reaqt मुद्दों में विशिष्ट प्रश्नों पर चर्चा कर सकते

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

const AsyncUser = props => fetchUser()
  .then(data => (
     <User {...data} />
   ))

यदि समर्थित है तो मुझे लगता है कि यह बहुत सारे जटिल कोड को समझने में आसान बना देगा और संभवतः नए एसिंक्स पैटर्न खोल देगा।

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

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

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

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

https://github.com/davnicwil/react-frontload

<AsyncComponent 
  delayRendering={LoadingComponent}
> 
   {/*return a promise that returns a component here*/}
</AsyncComponent>

सभी सशर्त प्रतिपादन के बारे में सोचें जो आपको उपरोक्त दृष्टिकोण से नहीं करना होगा क्योंकि आप जानते हैं कि आपके पास आपका डेटा है

इस में शामिल हो रहे हैं। मुझे लगता है कि यह अभी भी एक आवश्यक विशेषता है जिसमें रिएक्ट की कमी है। यह भी सहमत हैं कि भले ही तीसरे पक्ष के दायित्व इस विषय को कवर कर सकते हैं, यह सीधे भीतर से आना चाहिए।

मैं एक कार्यान्वयन के साथ आया https://github.com/timurtu/react-render-async

बहुत अच्छा async घटक इंटरफ़ेस, @timurtu।

...अरे सब लोग, बस यहाँ झंकार करना चाहता था क्योंकि मेरे पास कई चीजें हैं जो इस धागे से बहुत सीधे संबंधित हैं, और मैं इस धागे को लंबे समय से ट्रैक कर रहा हूं:

• एक के लिए, SSR पर विचार करते हुए, मुझे लगता है कि रूट-स्तरीय डेटा-फ़ेचिंग सबसे अधिक समझ में आता है - यहाँ क्यों है:
  Redux-फर्स्ट राउटर डेटा-फ़ेचिंग: async मिडलवेयर के लिए 80% उपयोग के मामले को हल करना
• Redux के साथ सर्वर रेंडरिंग अब बेवकूफी भरा सरल है, यहाँ Redux-First राउटर के साथ एक स्टेप बाय स्टेप गाइड है कि इसे कैसे किया जाए जैसे आपने इसे पहले कभी नहीं देखा है: सर्वर-रेंडर जैसे प्रो / w Redux-फर्स्ट राउटर 10 चरणों में
• अंत में, कोड-स्प्लिटिंग राइट करने के लिए, आपको दोनों (यानी SSR + स्प्लिटिंग दोनों) भी करने होंगे । यह एक साथ पता चला है कि दोनों एक प्रमुख दर्द बिंदु रहा है , कुछ लोगों द्वारा सफलतापूर्वक हासिल किया गया है, और अब तक समुदाय की मदद करने के लिए एक सामान्य पैकेज नहीं है। रिएक्ट यूनिवर्सल कंपोनेंट + babel-plugin-universal-import + वेबपैक-फ्लश-चंक्स (और एक्सट्रैक्ट-सीएसएस-चंक्स-वेबपैक-प्लगइन ) पैकेज का एक परिवार है जो वास्तव में इस मामले को हल करता है। और पहली बार। मूल रूप से, यह आपको सर्वर पर घटकों को समकालिक रूप से प्रस्तुत करने की अनुमति देता है, लेकिन इससे भी महत्वपूर्ण बात यह है कि क्लाइंट पर प्रारंभिक सिंक्रोनस रेंडर के लिए क्लाइंट को दिए गए सटीक विखंडू को भी स्थानांतरित करता है। आप वेबपैक प्लगइन के माध्यम से सीएसएस चंक स्टाइलशीट भी प्राप्त कर सकते हैं। यह @timurtu द्वारा साझा किए गए और कई ऐसे घटकों से अलग है, जिन्हें लोड करने की आवश्यकता होती है main.js , पार्सिंग, मूल्यांकन, प्रतिपादन और फिर अंत में कुछ सेकंड बाद गतिशील आयात का अनुरोध करना। ये अस्थिर सामग्री (एफओयूसी) के फ्लैश को हल करने के समाधान हैं, लेकिन आपके पृष्ठ में सर्वर पर प्रदान किए गए सटीक भाग को एम्बेड करने के लिए नहीं हैं। यूनिवर्सल - पैकेज के मेरे परिवार का नाम - आपको पारंपरिक वेबएप्स की तरह संचालित होने वाले सिंक्रोनस तरीके से इंटरएक्टिव (टीटीआई) समय के साथ ऐसा करने की अनुमति देता है। आप इस लेख में इसके बारे में अधिक जान सकते हैं: रिएक्ट यूनिवर्सल कंपोनेंट 2.0 और बेबेल-प्लगइन-सार्वभौमिक-आयात

मुझे पता है कि मैंने मार्ग स्तर बनाम घटक स्तर के पेशेवरों/विपक्षों को संबोधित नहीं किया है, लेकिन पहला लिंक मुख्य रूप से उस पर केंद्रित है। मूल रूप से यह एसएसआर के लिए खराब होने वाले घटक स्तर तक उबाल जाता है यदि आपके पास नेस्टेड घटक हैं जिनके डेटा को अनुक्रम में (समानांतर के बजाय) लाया जाना चाहिए। और यदि आपके पास प्रति मार्ग बनाने के लिए केवल एक ही फ़ेच है, तो ठीक है, आप componentDidMount में करने के बजाय अपनी डेटा निर्भरता को रूट इकाई से जोड़कर अनुबंध को औपचारिक रूप देना बेहतर समझते हैं। ऊपर के कई अन्य लोग भी इसी निष्कर्ष पर पहुंचे। Redux-First Router इसे "अनुबंधों" की तर्ज पर बहुत अच्छी तरह से औपचारिक रूप देता है जो Redux को काम करने के लिए इतना सुखद बनाता है।

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

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

RLR और RFR के बीच प्राथमिक अंतर यह है कि RFR हमेशा LOCATION_CHANGED बजाय प्रति मार्ग एक अलग क्रिया प्रकार (यानी URL परिवर्तन) भेजता है। यह आपको किसी भी अन्य क्रिया की तरह, अपने रिड्यूसर में URL परिवर्तनों को अद्वितीय प्रकारों के रूप में बदलने देता है। यह छोटा लग सकता है, लेकिन इससे बहुत फर्क पड़ता है। उसके कारण, इसे <Route /> घटकों की आवश्यकता नहीं है, कुछ ऐसा जो Redux भूमि में अनावश्यक है। सुविधाओं की एक विशाल लॉन्ड्री सूची भी है, Redux-First राउटर डेटा-फ़ेचिंग से रूट thunks में रिएक्ट नेटिव, रिएक्ट नेविगेशन, कोड स्प्लिटिंग, प्रीफ़ेचिंग, और बहुत कुछ का समर्थन करता है।

लोगों के विचार सुनना अच्छा लगेगा।

@faceyspacey धन्यवाद, मुझे लगता है कि यह उस समस्या का समाधान करता है जो मुझे हो रही थी, जब आप उदाहरण के लिए async डेटा के आधार पर प्रॉप्स सेट करना चाहते हैं, react-native-vector-icons एक वादे के रूप में एक आइकन वापस कर सकता है। यह निश्चित रूप से चीजों को देखने का एक अलग तरीका है लेकिन यह componentWillMount या redux X_GET_START , X_GET_END , और X_GET_ERROR एक्शन बॉयलरप्लेट को कम कर देता है जो एसिंक घटकों को राज्य से जोड़ता है, जब आप वास्तव में घटक को प्रस्तुत करने के लिए केवल एक बार अनुरोध करना चाहते हैं। यदि आप मतदान डेटा जैसी चीजें कर रहे हैं तो स्टेटफुल होना और रेडक्स का उपयोग करना शायद अधिक समझ में आता है

@faceyspacey मैं देख रहा हूं कि आप मार्ग स्तर के बारे में क्या कह रहे हैं, लेकिन क्या छोटे घटकों का होना बेहतर नहीं होगा जो केवल उनके आसपास की हर चीज को समकालिक रूप से प्रस्तुत करते समय उन्हें आवश्यक डेटा लाने पर निर्भर करते हैं?

बेहतर? कहां? प्रतिक्रिया मूल निवासी पर? फेसबुक जैसे बड़े संगठनों में उनके रिएक्ट नेटिव ऐप्स पर?

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

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

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

https://www.codesandbox.io

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

मुझे लगता है कि एसिंक रेंडर विधि का समर्थन करने का सबसे आसान तरीका होगा (रेंडर एक वादा देता है)। यह रूट कंपोनेंट वेट चिल्ड्रन कंपोनेंट्स रेंडरिंग की अनुमति देगा और निश्चित रूप से रेंडर का परिणाम एक वादा होगा। मैंने यहाँ उपदेश में कुछ इस तरह लागू किया https://github.com/3axap4eHko/preact-async-example

@faceyspacey ऊपर दिए गए विस्तृत उत्तर के लिए धन्यवाद। मुझे वास्तव में Redux-First राउटर का विचार पसंद है, यह निश्चित रूप से मेरी सभी समस्याओं का समाधान करता है, और चीजों को पहले की तुलना में कहीं अधिक पारदर्शी और स्वच्छ बनाता है।

बड़ा धन्यवाद!

@raRaRa खुशी है कि आपको यह पसंद आया! ...सबसे बड़ी चुनौतियों में से एक यह है कि अब तक रूट लेवल डेटा-फ़ेचिंग के लिए एक अच्छा एब्स्ट्रैक्शन नहीं हुआ है। रिएक्ट रिएक्ट v3 में कॉलबैक थे, और v4 में एक उत्कृष्ट पैटर्न है (विशेषकर react-router-config पैकेज के साथ), लेकिन यह स्पष्ट नहीं है और v4 में प्रथम श्रेणी नहीं है। यह एक बाद का विचार है। हालाँकि इससे भी महत्वपूर्ण बात यह है कि यह Redux में नहीं रहता है। तो यह वास्तव में अब पहली बार है कि redux उपयोगकर्ताओं के पास पूर्ण "मार्ग स्तर" अमूर्तता है।

मुझे लगता है कि अब RFR के साथ, हम "रूट लेवल" बनाम "कंपोनेंट लेवल" के महत्व पर फिर से विचार करने वाले हैं। रिले और अपोलो जैसी चीजों ने डेटा निर्भरता को घटकों से जोड़ने के बारे में बहुत प्रचार किया है, लेकिन यदि आप उन 2 का उपयोग नहीं कर रहे हैं, तो आप जीवनचक्र संचालकों में काम करके किसी बिंदु पर चोट की दुनिया में समाप्त होने जा रहे हैं। .

उस ने कहा कि अंततः आरएफआर का अपोलो के साथ रूट लेवल इंटीग्रेशन होगा। घटक स्तर पर चीजों को करने के लिए बहुत कम लाभ हैं, उपरोक्त दुर्लभ अपवादों को घटाकर। कम से कम 80% समय (और शायद आपके ऐप में 100%), आप मार्ग के आधार पर अपने लिए आवश्यक सभी डेटा निर्धारित कर सकते हैं। यदि यह संभव नहीं है, तो इसकी संभावना इसलिए है क्योंकि आप अपनी "दृश्य परत" में डेटा प्राप्त कर रहे हैं, जिसे बहुत अच्छी तरह से सोचा जा सकता है कि सभी को URL द्वारा व्याख्यायित किया जा सकता है। तो अपोलो जैसे उपकरणों के साथ भी आप समस्याग्रस्त विरोधी-पैटर्न में संलग्न होना शुरू कर देते हैं जो अंततः "राज्य" को कहीं और नहीं बल्कि दृश्य परत को रहने देकर आपको दर्द का कारण बनेंगे। यानी राज्य उन डेटा-फ़ेचिंग को करने के लिए आवश्यक है। आपको अक्सर अपना डेटा लाने के लिए उपयोग किए जाने वाले सटीक पैरामीटर को परिशोधित करना पड़ता है। तो आप डेटा लाने से ठीक पहले पैरा प्राप्त करने के लिए राज्य और प्रोप लेते हैं और 2 को बदलते हैं। यह वह सामान है जो अब दृश्य परत में रहता है और इसके पुन: प्रतिपादन तंत्र के अधीन होता है (यानी जब जीवनचक्र संचालकों को कहा जाता है)। प्रत्येक ऐप एक बिंदु या किसी अन्य पर डेटा के साथ समाप्त होता है जब इसे प्राप्त/बदले गए असंबंधित प्रोप के जवाब में प्राप्त किया जाना चाहिए या प्राप्त नहीं किया जाना चाहिए। और सभी ऐप्स में, आपको असंबंधित प्रॉप्स से बचाव के लिए अतिरिक्त कोड लिखना होगा जो बदल गए हैं। यानी प्रॉप्स जो डेटा लाने के लिए इस्तेमाल किए गए पैरा को प्रभावित नहीं करते हैं।

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

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

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

@faceyspacey मैं पूरी तरह सहमत हूं। लेकिन मुझे यह स्वीकार करना होगा कि मैंने अपोलो और न ही ग्राफक्यूएल की कोशिश नहीं की है, मैं निश्चित रूप से उनकी जांच करूंगा और देखूंगा कि वे मेरे उपयोग के मामलों में कैसे फिट होते हैं।

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

मैंने एमवीसी अनुप्रयोगों को देखा है जहां दृश्य भाग डेटा ला रहा है और व्यावसायिक तर्क कर रहा है, और यह भयानक है। दोनों मुझे कोई सुराग नहीं है कि कौन सा डेटा लाया जाएगा क्योंकि यह कुछ दृश्य/घटक में छिपा हुआ है और परीक्षण कठिन/असंभव हो जाता है।

मेरे लिए, रेडक्स-फर्स्ट राउटर एमवीसी में नियंत्रक भाग के साथ-साथ मार्गों की तरह है। जो इतना समझ में आता है :)

शुक्रिया।

दिन के अंत में, हमारा नया स्टैक यह है:

एम: रेडक्स
वी: प्रतिक्रिया
सी: रेडक्स-फर्स्ट राउटर (जल्द ही इसका नाम बदलकर "रूडी" कर दिया जाएगा)

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

यह नए क्लाइंट-प्रथम स्टैक बनाम पारंपरिक सर्वर-साइड एमवीसी में थोड़ा अलग तरीके से काम कर सकता है, लेकिन मूल रूप से यह वही 3 चिंताओं का अलगाव है।

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

नमस्कार दोस्तों इस लिंक को देखें। यहाँ डेटा सर्वर साइड रेंडरिंग उदाहरण है https://github.com/bananaoomarang/isomorphic-redux

@ harut55555 आईडीके यह सिर्फ मैं हो सकता है लेकिन यह एक अनुरोध प्राप्त करने और एक पोस्ट अनुरोध करने के लिए बहुत सारे कोड की तरह लगता है

कोई बदलाव? जारी 16 प्रतिक्रियाएँ और अधिकांश समाधान काम नहीं करते हैं

मुझे लगता है कि वर्तमान दृष्टिकोण रेडक्स ऑब्जर्वेबल या रेडक्स थंक जैसे टूलींग के साथ रेडक्स का उपयोग करता है

मेरे उपयोग का मामला

<App>
    <Page>
        <AsyncModule hre="different.com/Button.react.js" /> downloaded from external url on server or client
    </Page>
</App>

समस्या यह है कि ऐप को प्रस्तुत करने से पहले मुझे नहीं पता कि मेरे पास किस तरह के घटक होंगे

क्यों न केवल जिज्ञासु घटक के बजाय डेटा/सामग्री डाउनलोड करें?

कब? मेरे पास गतिशील पृष्ठ हैं और घटक हो भी सकता है और नहीं भी

लगता है जैसे आप सशर्त प्रतिपादन चाहते हैं https://reactjs.org/docs/conditional-rendering.html

मुझे लगता है कि यह रूटिंग समस्या है, प्रतिक्रिया केवल पृष्ठ प्रस्तुत करना चाहिए, प्रबंधन नहीं करना चाहिए और डेटा प्रस्तुत करने का अनुरोध करना चाहिए

अपोलो से @graphql का उपयोग करना डेटा लोडिंग को सुपर सरल बनाता है, और रिएक्ट-राउटर v4 घटक-आधारित एपीआई सरल कंपोज़ेबल रूटिंग के लिए बनाता है। दोनों Redux में एप्लिकेशन स्टेट के लिए ऑर्थोगोनल हैं।

सिंगल-पास स्ट्रीमिंग रेंडरिंग करने के लिए जो डेटा प्राप्त करने की प्रतीक्षा करता है, render() लिए एक वादा वापस करना संभव होना चाहिए (क्लाइंट पर आप अभी जैसा करते हैं, केवल सर्वर पर आप एक वादा वापस करते हैं)।

फिर @graphql डेटा लोड होने के बाद रेंडर() के लिए बस एक वादा वापस कर सकता है; बाकी सब सिर्फ सादा प्रतिक्रिया है।

कुछ महीने पहले मैंने JSConf आइसलैंड में एक भाषण दिया था जो रिएक्ट में आगामी async रेंडरिंग सुविधाओं का वर्णन करता है (दूसरा भाग देखें): https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react -16.एचटीएमएल। यह क्लाइंट-साइड डेटा लाने के बारे में है।

अब @acdlite ने इस बारे में बात की कि कैसे समान अवधारणाएं रिएक्ट घटकों में सर्वर पर डेटा के लिए अतुल्यकालिक रूप से प्रतीक्षा को सक्षम करने के लिए लागू हो सकती हैं, और मार्कअप को उत्तरोत्तर फ्लशिंग के रूप में तैयार कर सकती हैं: https://www.youtube.com/watch?v= z-6JC0_cOns

आशा है कि आप इन वार्ताओं को देखकर आनंदित होंगे! मुझे लगता है कि एक या दो साल में हम इस मुद्दे को खत्म करने में सक्षम हो सकते हैं और इसके लिए एक आधिकारिक रणनीति बना सकते हैं।

मुझे अंगूठी याद है। हम शादी कर रहे हैं एक साथ भविष्य की योजना बना रहे हैं। कृपया इसे अभी समाप्त करें और मुझसे मिलने आएं। समय ने हमेशा काम किया प्यार

पेड़ पर चलने के लिए ReactDOMServer.renderToStaticMarkup का उपयोग करना संभव है, एक बुकमार्क रखें जहां यह एसिंक्रोनस निर्भरता (आमतौर पर एक एपीआई से डेटा लोड हो रहा है) तक पहुंचता है, और पेड़ पर चलना जारी रखता है क्योंकि उन निर्भरताओं को हल किया जाता है, जब तक कि पूरा पेड़ हल नहीं हो जाता है, और फिर अंतिम ReactDOMServer.renderToString वास्तव में HTML को रेंडर करने के लिए करें, जो सिंक्रोनस होगा क्योंकि सभी निर्भरताएं अब हल हो गई हैं।

मैंने इस दृष्टिकोण को react-baconjs : render-to-html.js में लिया है । यह इस तरह के दृष्टिकोण की सिफारिश करने वाले एक अन्य मुद्दे में @gaearon की टिप्पणी से प्रेरित था।

@ स्टीव-टेलर हाँ, यह काम करता है। यह मेरे द्वारा रिएक्ट-फ्रंटलोड में उपयोग किया जाने वाला वर्कअराउंड भी है जो इसके लिए एक अधिक सामान्य उद्देश्य समाधान है जो किसी भी रिएक्ट ऐप में काम करेगा।

जैसा कि आप अनिवार्य रूप से कहते हैं कि यह केवल दो बार सिंक्रोनस रेंडरिंग लॉजिक चलाकर एसिंक्रोनस रेंडरिंग है और दूसरे को चलाने से पहले हल करने के लिए पहले रेंडर पर हिट किए गए सभी डेटा-लोडिंग वादों की प्रतीक्षा कर रहा है।

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

@davnicwil अच्छा काम! मैंने विशिष्ट एसिंक्स एसएसआर समाधान को सामान्य बनाने के बारे में सोचा है। क्या प्रतिक्रिया-फ्रंटलोड असीमित एसिंक गहराई को संभालता है? पूछ रहे हैं क्योंकि आपने "दो बार" कहा था।

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

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

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

FYI करें हमने इस पर काम शुरू कर दिया है।

https://reactjs.org/blog/2018/11/27/react-16-roadmap.html#suspense -for-server-rendering

बहुत बढ़िया @gaearon!

@davnicwil react-baconjs असीमित गहराई का समर्थन करता है।

@gaearon मुझे आश्चर्य है कि क्या यह क्रिएट-सब्सक्रिप्शन में

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

@ स्टीव-टेलर प्रतिक्रिया-फ्रंटलोड अब 1.0.7 रिलीज के साथ, घटक घोंसले की असीमित गहराई का भी समर्थन करता है।

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

हमने पहले इस समस्या का सामना किया था क्योंकि हमारा ऐप रिएक्ट हुक के साथ बनाया गया था, और फिर हमने इसे हल करने के लिए एक पैकेज प्रतिक्रिया-उपयोग-एपीआई बनाया, जो एक कस्टम हुक है जो एपीआई डेटा प्राप्त करता है और एसएसआर का समर्थन करता है। मुझे उम्मीद है कि पैकेज जरूरतमंद लोगों की मदद कर सकता है।

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