कोड विभाजन। कोड विभाजन हर जगह है। हालाँकि, क्यों? सिर्फ इसलिए कि आजकल बहुत अधिक जावास्क्रिप्ट है, और सभी एक ही समय में उपयोग में नहीं हैं।

JS बहुत भारी चीज है। आपके iPhone Xs या ब्रांड के नए i9 लैपटॉप के लिए नहीं, बल्कि धीमी डिवाइस के मालिकों के लाखों (शायद अरबों) के लिए। या, कम से कम, अपनी घड़ियों के लिए।

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

कोड विभाजन

आज हमारे पास जाने के दो तरीके हैं, इसे बेहतर बनाने के दो तरीके, या इसे और खराब न करने के लिए:

1. कम कोड लिखें

यही सबसे अच्छी बात है जो आप कर सकते हैं। जबकि React Hooks आपको थोड़ा कम कोड शिप करने दे रहे हैं, और Svelte जैसे समाधान आपको सामान्य से कम कोड उत्पन्न करने देते हैं, ऐसा करना इतना आसान नहीं है।

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

लघु और ध्वनि कोड लिखने के तरीके हैं, और विपरीत कार्यान्वयन लिखने के तरीके हैं - खूनी उद्यम । और, आप जानते हैं, दोनों वैध हैं।

लेकिन मुख्य मुद्दा - कोड ही। एक साधारण प्रतिक्रिया आवेदन आसानी से "अनुशंसित" 250kb को बायपास कर सकता है। और आप इसे अनुकूलित करने और इसे छोटा बनाने में एक महीना खर्च कर सकते हैं। "छोटे" अनुकूलन अच्छी तरह से प्रलेखित हैं और काफी उपयोगी हैं - बस size-limit साथ bundle-analyzer प्राप्त करें और आकार में वापस आ जाएं।
कई पुस्तकालय हैं, जो हर बाइट के लिए लड़ते हैं, आपको अपनी सीमा में रखने की कोशिश कर रहे हैं - कुछ को नाम देने के लिए प्रचार और स्टोरन ।

लेकिन हमारा आवेदन 200kb से थोड़ा आगे है। यह 100Mb के करीब है। किलोबाइट को हटाने से कोई मतलब नहीं है। यहां तक कि मेगाबाइट हटाने का भी कोई मतलब नहीं है।

कुछ पल बाद अपने आवेदन को छोटा रखना असंभव है। यह समय के साथ बड़ा होता जाएगा।

2. कम कोड जहाज

वैकल्पिक रूप से, code split । दूसरे शब्दों में - समर्पण । अपना 100mb का बंडल लें, और उसमें से बीस 5mb का बंडल बनाएं। ईमानदारी से - यह आपके आवेदन को संभालने का एकमात्र संभव तरीका है यदि यह बड़ा हो गया है - इससे छोटे ऐप्स का एक पैकेट बनाएं।

लेकिन एक बात है जो आपको अभी पता होनी चाहिए: आप जो भी विकल्प चुनते हैं, वह एक कार्यान्वयन विवरण है, जबकि हम कुछ अधिक विश्वसनीय की तलाश कर रहे हैं।

कोड विभाजन के बारे में सच्चाई

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

बस उस कोड को शिप न करें जिसकी आपको अभी आवश्यकता नहीं है। इससे छुटकारा पाओ।

कहना आसान है, करना कठिन। मेरे पास कुछ भारी हैं, लेकिन पर्याप्त रूप से विभाजित एप्लिकेशन नहीं हैं, जहां कोई भी पृष्ठ 50% सब कुछ की तरह लोड करता है। कभी-कभी code splitting code separation बन जाता है, मेरा मतलब है - आप कोड को अलग-अलग हिस्सों में स्थानांतरित कर सकते हैं, लेकिन फिर भी, यह सब उपयोग करें। याद रखें कि "बस उस कोड को शिप न करें जिसकी आपको अभी आवश्यकता नहीं है" , - मुझे कोड का 50% चाहिए था, और यही असली समस्या थी।

कभी-कभी यहां केवल import जोड़ना और पर्याप्त नहीं है। जब तक यह समय अलग नहीं होता है, लेकिन केवल अंतरिक्ष पृथक्करण - यह बिल्कुल भी मायने नहीं रखता है।

कोड विभाजन के 3 सामान्य तरीके हैं:

बस गतिशील import । इन दिनों बमुश्किल अकेले इस्तेमाल किया जाता है। यह एक राज्य पर नज़र रखने के साथ मुद्दों के बारे में अधिक है।
Lazy घटक, जब आप एक प्रतिक्रिया घटक के प्रतिपादन और लोडिंग को स्थगित कर सकते हैं। शायद 90% "प्रतिक्रिया कोड विभाजन" इन दिनों।
लेज़ी Library , जो वास्तव में है .1 , लेकिन आपको रिएक्ट रेंडर प्रॉप्स के माध्यम से लाइब्रेरी कोड दिया जाएगा। प्रतिक्रिया-आयातित-घटक और लोड करने योग्य-घटकों में लागू किया गया । काफी उपयोगी है, लेकिन अच्छी तरह से ज्ञात नहीं है।

घटक स्तर कोड विभाजन

यह सबसे लोकप्रिय है। प्रति-रूट कोड विभाजन, या प्रति-घटक कोड विभाजन। ऐसा करना इतना आसान नहीं है और इसके परिणामस्वरूप अच्छे अवधारणात्मक परिणाम बनाए हुए हैं। यह Flash of Loading Content से मौत है।

अच्छी तकनीकें हैं:

समानांतर में एक मार्ग के लिए js chunk और data लोड करें।
पेज लोड (फेसबुक की तरह) से पहले पृष्ठ के समान कुछ प्रदर्शित करने के लिए एक skeleton का उपयोग करें।
prefetch चंक्स, आप एक बेहतर भविष्यवाणी के लिए अनुमान-जैस का उपयोग भी कर सकते हैं।
संक्रमण को नरम करने के लिए कुछ देरी, लोडिंग इंडिकेटर्स, animations और Suspense (भविष्य में) का उपयोग करें।

और, आप जानते हैं, यह सब अवधारणात्मक प्रदर्शन के बारे में है।

भूत तत्वों के साथ बेहतर UX से छवि

यह अच्छा नहीं लगता

तुम्हें पता है, मैं खुद को कोड विभाजन में एक विशेषज्ञ कह सकता हूं - लेकिन मेरी अपनी विफलताएं हैं।

कभी-कभी मैं बंडल आकार को कम करने में विफल हो सकता था। कभी-कभी मैं परिणामी प्रदर्शन में सुधार करने में विफल हो सकता है, जब तक कि the _more_ code splitting you are introducing - the more you spatially split your page - the more time you need to _reassemble_ your page back *। इसे लोडिंग वेव्स कहा जाता है।

SSR या पूर्व-प्रतिपादन के बिना। उचित SSR इस समय एक गेम चेंजर है।

पिछले हफ्ते मुझे दो असफलताएँ मिली हैं:

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

रिएक्ट-डोम 20% था, कोर-जेएस 10% था, रिएक्शन-राउटर, jsLingui, रिएक्शन-पॉवरप्लग ... 20% खुद का कोड ... हम पहले से ही कर रहे हैं।

समाधान

मैंने यह सोचना शुरू कर दिया है कि अपनी समस्या को कैसे हल किया जाए, और मेरे उपयोग के मामले में सामान्य समाधान ठीक से काम क्यों नहीं कर रहे हैं।

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

यह एक आश्चर्य था। लेकिन मेरी समस्या CSS में थी। वेनिला सीएसएस संक्रमण में।

यहाँ कोड है

एक नियंत्रण चर - DisplayData , अंततः कुछ के लिए सेट किया जाएगा DisplayData को प्रदर्शित करना चाहिए।

एक बार मान सेट हो जाने पर - DisplayData दृश्यमान हो जाता है, बदलते className , इस प्रकार फैंसी संक्रमण को ट्रिगर करता है। FocusLock सक्रिय हो कर DisplayData एक मोडल बना DisplayData है।

 <FocusLock enabled={componentControl.value} // ^ it's "disabled". When it's disabled - it's dead. > {componentControl.value && <PageTitle title={componentControl.value.title}/>} // ^ it's does not exists. Also dead <DisplayData data={componentControl.value} visible={componentControl.value !== null} // ^ would change a className basing on visible state /> // ^ that is just not visible, but NOT dead </FocusLock>

मैं इस टुकड़े को एक पूरे के रूप में विभाजित करना चाहता हूं, लेकिन यह कुछ ऐसा है जो मैं नहीं कर सकता, दो कारणों से:

सूचना बिना किसी देरी के तुरंत, एक बार आवश्यक दिखाई देनी चाहिए। एक व्यावसायिक आवश्यकता।
जानकारी "क्रोम" से पहले मौजूद होना चाहिए, संपत्ति संभाल संक्रमण के लिए।

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

एक बेहतर तरीका होना चाहिए!

टीएल; डीआर - यहां दो प्रमुख बिंदु हैं:

DisplayData को माउंट किया जाना है , और DOM से पहले मौजूद है।
FocusLock भी पहले से मौजूद होना चाहिए, DisplayData रिमाउंट का कारण नहीं होना चाहिए, लेकिन यह शुरुआत में दिमाग की जरूरत नहीं है ।

तो चलिए अपने मानसिक मॉडल को बदलते हैं

बैटमैन और रॉबिन

मान लेते हैं कि हमारा कोड बैटमैन और रॉबिन है। बैटमैन सबसे बुरे लोगों को संभाल सकता है, लेकिन जब वह नहीं कर सकता, तो उसकी साइडकिक रॉबिन बचाव के लिए आता है।

एक बार फिर बैटमैन लड़ाई में शामिल होगा, रॉबिन बाद में पहुंचेगा।

यह बैटमैन है:

 +<FocusLock - enabled={componentControl.value} +> - {componentControl.value && <PageTitle title={componentControl.value.title}/>} + <DisplayData + data={componentControl.value} + visible={componentControl.value !== null} + /> +</FocusLock>

यह उनकी साइडकिक है, रॉबिन ::

 -<FocusLock + enabled={componentControl.value} -> + {componentControl.value && <PageTitle title={componentControl.value.title}/>} - <DisplayData - data={componentControl.value} - visible={componentControl.value !== null} - /> -</FocusLock>

बैटमैन और रॉबिन एक टीम बना सकते हैं , लेकिन वे वास्तव में दो अलग-अलग व्यक्ति हैं।

और मत भूलना - हम अभी भी कोड विभाजन के बारे में बात कर रहे हैं। और, कोड विभाजन के संदर्भ में, साइडकिक कहां है? रॉबिन कहाँ है?

एक फुटपाथ में। रॉबिन एक साइडकार चंक में इंतजार कर रहा है।

एक प्रकार का मादक द्रव्य

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

यह एक ऊर्ध्वाधर कोड विभाजन को कॉल करना बेहतर होगा जहां कोड शाखाएं समानांतर में मौजूद हैं, एक सामान्य क्षैतिज कोड विभाजन के विपरीत जहां कोड शाखाएं कट जाती हैं ।

कुछ भूमि में , इस तिकड़ी को replace reducer या अन्य तरीकों से आलसी लोड redux तर्क और दुष्प्रभावों के रूप में जाना जाता था।

कुछ अन्य भूमि में , इसे "3 Phased" code splitting रूप में जाना जाता है।

यह केवल मामलों का एक और अलगाव है, केवल उन मामलों पर लागू होता है, जहां आप किसी घटक के कुछ हिस्से को लोड करना स्थगित कर सकते हैं, लेकिन किसी अन्य भाग को नहीं।

चरण 3

नई facebook.com के निर्माण की छवि प्रतिक्रिया, ग्राफक्लाइन और रिले के साथ , जहाँ importForInteractions , या importAfter हैं ।

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

परिणामस्वरूप - बैटमैन अकेले एक ग्राहक के लिए कुछ अधिक सहने योग्य है - वह कम कीमत पर अधिक मूल्य प्रदान करता है। तुम मेरे हीरो हो बैट!

क्या एक फुटपाथ में ले जाया जा सकता है:

बहुमत का useEffect , useEffect और दोस्त।
सभी मोडल प्रभाव पसंद है। यानी focus और scroll लॉक। आप पहले एक मोडल प्रदर्शित कर सकते हैं, और उसके बाद ही मोडल मोडल बना सकते हैं , अर्थात ग्राहक का ध्यान "लॉक" करें।
फार्म। सभी तर्क और मान्यताओं को एक फुटपाथ पर ले जाएँ, और उस तर्क को लोड होने तक फ़ॉर्म को जमा करें। ग्राहक फॉर्म भरना शुरू कर सकता है, यह जानते हुए कि यह केवल Batman ।
कुछ एनिमेशन। मेरे मामले में एक पूरी react-spring ।
कुछ दृश्य सामान। कस्टम स्क्रॉलबार की तरह, जो कि दूसरी बार फैंसी स्क्रॉल-बार प्रदर्शित कर सकता है।

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

आज हमारे ऐप्स में कोड स्प्लिटिंग अधिक हो सकता है। हमें एहसास होना चाहिए कि विभाजित करने के लिए कोड के 2 प्रकार हैं: 1) दृश्य पहलू 2) इंटरैक्टिव पहलू। बाद वाले कुछ क्षण बाद आ सकते हैं। Sidecar यह दो कार्यों को विभाजित करने के लिए सहज बनाता है, इस धारणा को देते हुए कि सब कुछ तेजी से लोड होता है । और यह होगा।

कोड विभाजन का सबसे पुराना तरीका

हालांकि यह अभी भी स्पष्ट नहीं हो सकता है कि कब और क्या एक sidecar है, मैं एक सरल विवरण दूंगा:

Sidecar आपके सभी अधिकार हैं । सीडेकर वह तरीका है जिससे हम आज जो कुछ भी प्राप्त करते हैं, उससे पहले सभी चीजों को कोडप्लेट करते हैं।

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

हमारे पास एचटीएमएल, प्लस सीएसएस, प्लस कुछ स्क्रिप्ट्स इनलाइन, साथ ही बाकी स्क्रिप्ट्स .js फाइलों में निकाली गई हैं।

HTML + CSS + inlined-js Batman थे, जबकि बाहरी स्क्रिप्ट Robin थे, और साइट रॉबिन के बिना कार्य करने में सक्षम थी, और, ईमानदारी से, आंशिक रूप से बैटमैन के बिना (वह दोनों पैरों के साथ लड़ाई जारी रखेगी) (इनलाइन स्क्रिप्ट्स टूटी हुई)। यह सिर्फ कल था, और कई "गैर आधुनिक और शांत" साइटें आज भी समान हैं।

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

उदाहरण के लिए - Theurge.com , जो React में लिखा गया है, पूरी तरह से बिना किसी js सक्षम के कार्यात्मक है।

वहाँ बहुत सी चीजें हैं जो आप एक फुटपाथ पर उतार सकते हैं। उदाहरण के लिए:

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

जरा सोचिए कि आपके आवेदन के लिए क्या जरूरी है, और क्या नहीं ...

कार्यान्वयन का विवरण

(DI) घटक कोड विभाजन

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

 const SmartComponent = React.lazy( () => import('./SmartComponent')); class DumbComponent extends React.Component { render() { return ( <React.Fragment> <SmartComponent ref={this} /> // <-- move smart one inside <TheActualMarkup /> // <-- the "real" stuff is here </React.Fragment> } }

इसके लिए डम्ब वन के लिए इनिशियलाइज़ेशन कोड भी आवश्यक है, लेकिन आप अभी भी किसी कोड के सबसे भारी हिस्से को कोड-विभाजित करने में सक्षम हैं।

क्या आप अब एक parallel या vertical कोड विभाजन पैटर्न देख सकते हैं?

useSidecar

नई facebook.com को React, GraphQL और रिले के साथ बनाना , मैंने पहले ही यहाँ उल्लेख किया है, इसमें loadAfter या importForInteractivity की अवधारणा थी, जो काफी समान है।

उसी समय में, मैं आपको useSidecar तरह कुछ बनाने की सलाह नहीं useSidecar जब तक कि आप जानबूझकर hooks अंदर का उपयोग करने की कोशिश नहीं कर सकते, लेकिन इस रूप में कोड विभाजन हुक के नियम को तोड़ देगा।

कृपया अधिक घोषणात्मक घटक तरीका पसंद करें। और आप SideCar घटक के अंदर hooks उपयोग कर सकते हैं।

 const Controller = React.lazy( () => import('./Controller')); const DumbComponent = () => { const ref = useRef(); const state = useState(); return ( <> <Controller componentRef={ref} state={state} /> <TheRealStuff ref={ref} state={state[0]} /> </> ) }

प्रीफेचिंग

भूल न करें - आप लोडिंग प्राथमिकता का उपयोग कर सकते हैं ताकि प्रीलोड या प्रीफैच sidecar को लोड किया जा सके और इसे शिपिंग को अधिक पारदर्शी और अदृश्य बनाया जा सके।

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

एसएसआर

सामान्य कोड विभाजन के विपरीत, एसएसआर के लिए कोई विशेष कार्रवाई की आवश्यकता नहीं है। Sidecar एसएसआर प्रक्रिया का हिस्सा नहीं हो सकता है और hydration कदम से पहले इसकी आवश्यकता नहीं है। इसे "डिज़ाइन द्वारा" स्थगित किया जा सकता है।

इस प्रकार - React.lazy का उपयोग करने के लिए स्वतंत्र महसूस करें (आदर्श रूप से कुछ Suspense बिना , आपको यहां किसी भी असफलता (लोडिंग) संकेतक की आवश्यकता नहीं है, या किसी अन्य पुस्तकालय के साथ, लेकिन SSR प्रक्रिया के दौरान साइडकार चंक्स को छोड़ने के लिए SSR समर्थन के बिना बेहतर है।

बुरे हिस्से

लेकिन इस विचार के कुछ बुरे हिस्से हैं

बैटमैन एक प्रोडक्शन नाम नहीं है

हालांकि Batman / Robin एक अच्छा माइंड कॉन्सेप्ट हो सकता है, और sidecar तकनीक के लिए एक सही मैच है - maincar लिए कोई "अच्छा" नाम नहीं है। maincar जैसी कोई चीज नहीं है, और जाहिर है कि Batman , Lonely Wolf , Solitude , Driver और Solo उपयोग नॉन-साइडकार भाग के नाम के लिए नहीं किया जाएगा।

फेसबुक ने display और interactivity उपयोग किया है, और यह हम सभी के लिए सबसे अच्छा विकल्प हो सकता है।

यदि आपके पास मेरे लिए एक अच्छा नाम है - तो इसे टिप्पणियों में छोड़ दें

पेड़ का हिलना

यह बंडलर दृष्टिकोण से चिंताओं के अलगाव के बारे में अधिक है। आइए कल्पना करें कि आपके पास Batman और Robin । और stuff.js

stuff.js

 export * from `./batman.js` export * from `./robin.js`

फिर आप एक साइडकार को लागू करने के लिए घटक घटक कोड विभाजन की कोशिश कर सकते हैं

main.js

 import {batman} from './stuff.js' const Robin = React.lazy( () => import('./sidecar.js')); export const Component = () => ( <> <Robin /> // sidecar <Batman /> // main content </> )

sidecar.js

 // and sidecar.js... that's another chunk as long as we `import` it import {robin} from './stuff.js' .....

संक्षेप में - उपरोक्त कोड काम करेगा, लेकिन "नौकरी" नहीं करेगा।

यदि आप सामान से केवल batman का उपयोग कर रहे हैं। stuff.js - वृक्ष stuff.js केवल इसे रखेगा।
यदि आप सामान से केवल robin का उपयोग कर रहे हैं। stuff.js - वृक्ष stuff.js केवल इसे रखेगा।
लेकिन अगर आप दोनों का उपयोग कर रहे हैं, यहां तक कि अलग-अलग हिस्सों में भी - दोनों सामान की पहली घटना में बंडल किए stuff.js । यानी, मुख्य बंडल ।

ट्री हिलाना कोड-विभाजन के अनुकूल नहीं है। आपको फ़ाइलों द्वारा चिंताओं को अलग करना होगा।

संयुक्त राष्ट्र के आयात

एक और बात, हर कोई भूल गया, जावास्क्रिप्ट की लागत है। यह jQuery के युग में काफी सामान्य था, स्क्रिप्ट को लोड करने के लिए jsonp पेलोड का युग ( json पेलोड के साथ), पेलोड प्राप्त करें, और स्क्रिप्ट को निकालें ।

आजकल हम सभी स्क्रिप्ट import , और यह हमेशा के लिए आयात किया जाएगा, भले ही अब इसकी आवश्यकता न हो।

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

संभवतः un-import की क्षमता (वेबपैक इसे कर सकता है ) एक कारण है कि हमें घटक-आधारित एपीआई के साथ रहना चाहिए, जब तक कि यह हमें unmount को संभालने की क्षमता देता है।

अब तक - ईएसएम मॉड्यूल मानकों में सामान के बारे में ऐसा कुछ नहीं है - और न ही कैश नियंत्रण के बारे में, और न ही आयात कार्रवाई को उलटने के बारे में।

फुटपाथ-सक्षम लाइब्रेरी बनाना

आज तक sidecar सक्षम पुस्तकालय बनाने का केवल एक ही तरीका है:

अपने घटक को भागों में विभाजित करें
index माध्यम से एक main भाग और connected हिस्सा (एपीआई को तोड़ने के लिए नहीं) को उजागर करें
एक अलग प्रविष्टि बिंदु के माध्यम से एक sidecar को उजागर करें।
लक्ष्य कोड में - main भाग को आयात करें और sidecar - पेड़ को हिलाने के लिए एक connected हिस्सा काटना चाहिए।

इस बार पेड़ को हिलाते हुए ठीक से काम करना चाहिए, और एकमात्र समस्या यह है कि main भाग का नाम कैसे दिया जाए।

main.js

 export const Main = ({sidecar, ...props}) => ( <div> {sidecar} .... </div> );

connected.js

 import Main from './Component'; import Sidecar from './Sidecar'; export const Connected = props => ( <Main sidecar={<Sidecar />} {...props} /> );

index.js

 export * from './Main'; export * from './Connected';

sidecar.js

 import * from './Sidecar';

संक्षेप में, परिवर्तन को एक छोटी तुलना के माध्यम से दर्शाया जा सकता है

 //your app BEFORE import {Connected} from 'library'; // // ------------------------- //your app AFTER, compare this core to `connected.js` import {Main} from 'library'; const Sidecar = React.lazy(import( () => import('library/sidecar'))); // ^ all the difference ^ export SideConnected = props => ( <Main sidecar={<Sidecar />} {...props} /> ); // ^ you will load only Main, Sidecar will arrive later.

सैद्धांतिक रूप से dynamic import का उपयोग नोड_मॉड्यूल्स के अंदर किया जा सकता है, जिससे प्रक्रिया को अधिक पारदर्शी बनाया जा सकता है।

वैसे भी - यह children / slot पैटर्न से ज्यादा कुछ नहीं है, इसलिए रिएक्ट में आम है।

भविष्य

Facebook ने साबित कर दिया कि विचार सही है। यदि आपने वह वीडियो नहीं देखा है - तो अभी करें। मैंने बस एक ही विचार को थोड़ा अलग कोण से समझाया है (और F8 सम्मेलन से एक सप्ताह पहले इस लेख को लिखना शुरू किया है)।

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

Sidecar , शायद, एकमात्र तरीका है, पुराने स्कूल एसएसआर को छोड़कर, बीआईजी कोड बेस को संभालने के लिए। कोड का एक न्यूनतम राशि जहाज करने का अंतिम मौका, जब आपके पास बहुत कुछ हो।

यह एक बड़ा अनुप्रयोग छोटा कर सकता है, और एक छोटा अनुप्रयोग और भी छोटा कर सकता है।

10 साल पहले मध्यम वेबसाइट 300ms में "तैयार" थी, और वास्तव में कुछ मिलीसेकंड के बाद तैयार थी। आज सेकंड और यहां तक कि 10 सेकंड से अधिक सामान्य संख्या हैं। क्या शर्म की बात है।

आइए एक विराम लें, और सोचें - हम समस्या को कैसे हल कर सकते हैं, और UX को फिर से महान बना सकते हैं ...

संपूर्ण

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

आइए इस बारे में बातचीत करें ।

बंद करो! तो जिन समस्याओं को हल करने की आपने कोशिश की, उनका क्या?

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

एक कोड विभाजन के लिए साइडकार