प्रतिक्रिया और कोड विभाजन

मैं एक बहुत समय पहले कोड विभाजन से मिला था, वर्ष 2008 में, जब Yandex थोड़ा निलंबित था, और Yandex.Direct लिपियों को साइट से कनेक्ट करने के लिए इस साइट को आसानी से मार दिया गया था। सामान्य तौर पर, यह उन दिनों सामान्य था यदि आपकी "स्क्रिप्ट" 10 फाइलें हैं जिन्हें आप एकमात्र सही क्रम में कनेक्ट करते हैं, जो अभी भी (डिफर के साथ) अभी भी ठीक काम करता है।
फिर मैंने कार्ड के साथ सक्रिय रूप से काम करना शुरू कर दिया, और वे अभी भी बाहरी लिपियों के रूप में जुड़े हुए हैं, बेशक आलसी-लोड। फिर, Yandex.Mart टीम के एक सदस्य के रूप में, मैंने क्लाइंट पर सक्रिय रूप से ymodules ट्री- शेकिंग सुविधा का उपयोग किया, जो सिर्फ सही कोड विभाजन प्रदान करता था।

और फिर मैं भयभीत बेवकूफों के देश के लिए webpack और React , जिन्होंने नए गेट पर एक राम की तरह require.ensure को देखा। और अब भी करते हैं।

कोड विभाजन एक वाह सुविधा नहीं है, यह एक होना चाहिए। फिर भी SSR हस्तक्षेप नहीं करेगा ...

छोटा सा परिचय

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

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

अभी अधिक या कम "आधिकारिक" विकल्प React.lazy और लोड करने योग्य-घटक (बस @loadable लोड करने योग्य ) होंगे, और उनके बीच का चुनाव स्पष्ट है:

• React.lazy SSR (सर्वर साइड रेंडरिंग) में पूरी तरह से असमर्थ है, सामान्य रूप से शब्द से। यहां तक ​​कि परीक्षणों में, यह एक टैम्बोरिन के साथ विशेष नृत्य के बिना गिर जाएगा, जैसे कि "तुल्यकालिक वादे"।
• एक लोड करने योग्य SSR, और सस्पेंस का समर्थन करते हुए, React.Lazy से बदतर नहीं हैं।

विशेष रूप से, लोड करने योग्य पुस्तकालयों के लिए सुंदर रैपर का समर्थन करता है (loadable.lib, आप React रेंडरप्रॉप में क्षणों को ले जा सकते हैं), और प्रीबुकिंग के लिए उपयोग की जाने वाली स्क्रिप्ट, शैलियों और संसाधनों की एक सूची एकत्र करने के लिए सर्वर साइड पर वेबपैक की मदद करता है (जो वेबपैक खुद वास्तव में नहीं जानता है)। सामान्य तौर पर, आधिकारिक दस्तावेज पढ़ें।

एसएसआर

सामान्य तौर पर, संपूर्ण समस्या एसएसआर में है। CSR (क्लाइंट साइड रेंडर) के लिए, या तो React.lazy या 10 लाइनों वाली एक छोटी स्क्रिप्ट फिट होगी - यह निश्चित रूप से पर्याप्त होगा, और यह एक बड़े बाहरी पुस्तकालय को जोड़ने के लिए कोई मतलब नहीं है। लेकिन सर्वर पर यह पर्याप्त नहीं होगा। और अगर आपको वास्तव में SSR की आवश्यकता नहीं है, तो आप आगे पढ़ना छोड़ सकते हैं। आपको कोई समस्या नहीं है जिसे लंबे और कठिन हल करने की आवश्यकता है।

एसएसआर एक दर्द है। मैं (किसी तरह से) लोड करने योग्य घटकों में से एक है और यह सिर्फ भयानक है कि विभिन्न स्थानों से कितने कीड़े निकलते हैं। और हर अपडेट के साथ वेबपैक और भी ज्यादा उड़ता है।

एसएसआर + सीएसएस

SSRs के साथ समस्याओं का एक बड़ा स्रोत CSS है।
यदि आपके पास स्टाइलेड-कंपोनेंट्स हैं - तो यह बहुत नुकसान नहीं पहुँचाता है - वे transform-stream साथ आते हैं जो कि अंतिम कोड के लिए आवश्यक चीज़ों को जोड़ देगा। मुख्य बात यह है कि हर जगह एससी का एक संस्करण होना चाहिए, अन्यथा फोकस काम नहीं करेगा - एससी का एक संस्करण अपने बारे में और कुछ भी नहीं बता पाएगा, और एससी नस्ल (अपने बंडल की जांच) करना पसंद करता है। ईमानदार होना, इस सीमा के कारण ठीक है कि फोकस आमतौर पर विफल रहता है ।

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

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

कनेक्शन आदेश

यहां कुत्ते ने ही दफनाया। मुझे कब कनेक्ट करना चाहिए?
SSR फ्रेंडली कोड स्प्लिटिंग का अर्थ यह है कि ReactDOM.hydrate कॉल करने से पहले ReactDOM.hydrate आपको उन सभी "घटकों" को डाउनलोड करने की आवश्यकता होती है जो पहले से ही सर्वर की प्रतिक्रिया में मौजूद हैं, लेकिन वर्तमान में क्लाइंट पर भरी गई स्क्रिप्ट बर्दाश्त नहीं कर सकती हैं।

इसलिए, सभी पुस्तकालय एक निश्चित कॉलबैक की पेशकश करते हैं जिसे तब कॉल किया जाएगा जब सभी-सभी-सभी को लोड करने की आवश्यकता होती है, और आप मस्तिष्क शुरू कर सकते हैं। यह SSR कोडिंग लाइब्रेरी के काम का अर्थ है।

जेएस को किसी भी समय लोड किया जा सकता है, और आमतौर पर उनकी सूची HTML के अंत में जोड़ दी जाती है, लेकिन CSS, ताकि कोई FOUC न हो, को शुरुआत में जोड़ना होगा।
सभी लाइब्रेरी पुराने renderToString लिए ऐसा करने में सक्षम हैं, और सभी लाइब्रेरी renderToNodeStream लिए ऐसा करने में सक्षम नहीं हैं।
इससे कोई फर्क नहीं पड़ता कि आपके पास केवल जेएस (ऐसा नहीं होता है), या एससी / भावना (जो खुद को जोड़ देगा)। लेकिन - अगर आपके पास "बस सीएसएस" है - यही है। या तो वे अंत में होंगे, या उन्हें renderToString , या अन्य बफरिंग का उपयोग renderToString होगा, जो टीटीएफबी (टाइम टू फर्स्ट बाइट) विलंब प्रदान करेगा और सामान्य रूप से इस एसएसआर को होने का एहसास कम करेगा।

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

अगला एक तीन-भाग का एजेंडा है, जिसका मुख्य विचार कुछ ऐसा करना है जो मारा नहीं गया है और बंडल पर निर्भर नहीं है।

1. प्रतिक्रिया-आयातित-घटक

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

विचार बहुत सरल है।

• स्रोत कोड स्कैन किए जाते हैं, सभी import किए जाते हैं और एक अलग फ़ाइल में कॉपी किए जाते हैं
• import करने के लिए हर कॉल babel plugin का उपयोग कुछ चीनी में बदल जाता है
  

   const AsyncComponent1 = imported(() => import('./MyComponent')); ///// const AsyncComponent1 = imported(() => importedWrapper("imported_18g2v0c_component", import('./MyComponent'))); 

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

stats.json को stats.json करने की आवश्यकता नहीं है, stats.json ऑप्टिमाइज़ेशन ( stats.json , या कॉमन कोड) के लिए अनुकूल है - आपको केवल सरणी में कुंजी में एक आयात के "लेबल" से मिलान करने और फिर से आयात करने की आवश्यकता है। यह एक विशिष्ट बंडल के हिस्से के रूप में कैसे किया जाएगा, वास्तव में कितनी फाइलें डाउनलोड की जाएंगी और कहां से उनकी समस्या नहीं है।

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

हां, सीसीएस के साथ यह किसी भी तरह से शब्द से काम नहीं करता है।

2. प्रयुक्त-शैली

लेकिन प्रयुक्त-शैली केवल सीएसएस के साथ काम करती है, लेकिन बहुत कुछ उसी तरह से जैसे कि प्रतिक्रिया-आयातित-घटक।

• सभी सीएसएस (निर्माण निर्देशिका में) को स्कैन करता है
• याद है कि किस वर्ग को कहां परिभाषित किया गया है
• स्कैन आउटपुट रेंडरToNodeStream (या renderToString प्रतिक्रिया)
• वर्ग = 'XXX' पाता है, फ़ाइल से मेल खाता है और सर्वर प्रतिक्रिया में इसे बाहर थूकता है।
• (ठीक है, और फिर सिर को ऐसी सभी शैलियों को टेलीपोर्ट करता है ताकि हाइड्रेट को न तोड़ें)। स्टाइल कंपोनेंट्स सिर्फ एक ही काम करते हैं।

कोई TTBT विलंब नहीं है, यह बंडलर से बंधा नहीं है - एक परी कथा। एक घड़ी की तरह काम करता है अगर शैलियों को अच्छी तरह से लिखा जाए।

प्रतिक्रिया-आयात-घटक + प्रयुक्त-शैलियाँ + पार्सल काम करने का उदाहरण।

सबसे स्पष्ट बोनस नहीं है - सर्वर पर, दोनों लाइब्रेरी स्टार्टअप के दौरान "सब कुछ जो आवश्यक है" करेंगे, जब तक कि एक्सप्रेस सर्वर पहले क्लाइंट को प्राप्त नहीं कर सकता है, और सर्वर पर और परीक्षणों के दौरान पूरी तरह से सिंक्रनाइज़ किया जाएगा।

3. प्रतिक्रिया-पूर्व-घटक

और पुस्तकालय शीर्ष तीन को बंद कर देता है, जो "आंशिक पुनर्जलीकरण" करता है, और यह इस तरह के दादाजी तरीके से करता है कि मुझे बहुत आश्चर्य होता है। वह वास्तव में "दिवस" ​​जोड़ता है।

• सर्वर पर:
  
  • "प्रसिद्ध आईडी" के साथ एक div में लकड़ी का एक टुकड़ा लपेटता है
• ग्राहक पर:
  
  • कंपोनेंट कंस्ट्रक्टर अपना डिव खुद ढूंढता है
  • React को लेने से पहले उसके आंतरिक HTML को कॉपी करता है।
  • जब तक क्लाइंट hydrate करने के लिए तैयार नहीं हो जाता तब तक इस HTML का उपयोग करता hydrate
  • तकनीकी रूप से, यह हाइब्रिड SSR (रेंडर्ट्रॉन) के उपयोग की अनुमति देता है

 const AsyncLoadedComponent = loadable(() => import('./deferredComponent')); const AsyncLoadedComponent = imported(() => import('./deferredComponent')); <PrerenderedComponent live={AsyncLoadedComponent.preload()} // when Promise got resolve - component will go "live" > <AsyncLoadedComponent /> // meanwhile you will see "preexisting" content </PrerenderedComponent> 

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

कोड के दृष्टिकोण से, यह 10 लाइनें है, साथ ही साथ कोड के लोडिंग और निष्पादन के यादृच्छिक क्रम को ध्यान में रखते हुए SSR-CSR UIDs प्राप्त करने के लिए थोड़ा अधिक है।

बोनस:

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

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

कुल मिलाकर

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

पुस्तकालयों के लिए लिंक:

• https://github.com/theKashey/react-imported-component/
• https://github.com/theKashey/react-prerendered-component
• https://github.com/theKashey/used-styles
• https://github.com/smooth-code/loadable-components/
• (जो टैंक में हैं उनके लिए) https://reactjs.org/blog/2018/10/23/react-v-16-6.html#reactlazy-code-splitting-with-suspense

लेख (अंग्रेजी में)

• (आयातित के बारे में) https://hackernoon.com/react-and-code-splitting-made-easy-f118befb5168
• (पहले से रेंडर के बारे में) https://medium.com/@antonkorzunov/react-server-side-code-splitting-made-again-a61f8cbd64b
• (SSR के बारे में) https://developers.google.com/web/updates/2019/02/rendering-on-the-web#partial-rehydration