🌃 ⛅️ 🦓 उत्पादन में जावास्क्रिप्ट मॉड्यूल का उपयोग करना: मामलों की वर्तमान स्थिति। भाग २ 🌌 🤭 🏚️

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

गतिशील आयात

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

और यदि आप कोड के आलसी लोडिंग को व्यवस्थित करने के लिए डायनामिक import() कमांड का उपयोग करना चाहते हैं, तो आपको इस तथ्य से निपटना होगा कि कुछ ब्राउज़र, हालांकि, सबसे निश्चित रूप से, मॉड्यूल का समर्थन करते हैं , फिर भी डायनेमिक आयात () कमांड का समर्थन नहीं करते हैं (एज 16-18, फ़ायरफ़ॉक्स 60-66, सफारी 11, क्रोम 61-63)।

सौभाग्य से, यह समस्या हमें एक छोटे (लगभग 400 बाइट्स आकार में) और बेहद तेज पॉलीफिल को हल करने में मदद करेगी।

इस पॉलीफ़िल को वेब प्रोजेक्ट में जोड़ना बहुत सरल है। आपको इसे आयात करने की आवश्यकता है और इसे कोड में मुख्य प्रविष्टि बिंदु पर आरंभ करना है import() कोड में किसी भी import() आदेशों को कॉल करने से पहले):

 import dynamicImportPolyfill from 'dynamic-import-polyfill'; //         .   //    ,       . dynamicImportPolyfill.initialize({modulePath: '/modules/'});

और आखिरी चीज जो इस योजना को काम करने के लिए करने की आवश्यकता है, वह है रोलअप को यह बताने के लिए कि उसे डायनामिक import() कमांड का नाम बदलने की जरूरत है जो आपके द्वारा चुने गए नाम ( आउटपुट . dynamicImportF विकल्प के माध्यम से) का उपयोग करके कोड में दिखाई देता है। एक __import__ जो गतिशील आयात सुविधा को लागू करता है, डिफ़ॉल्ट रूप से __import__ नाम का उपयोग करता है, लेकिन इसे अनुकूलित किया जा सकता है ।

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

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

कुशल जावास्क्रिप्ट लोड हो रहा है

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

लेकिन जब हम वास्तविक जावास्क्रिप्ट मॉड्यूल ( <script type="module"> और फिर संबंधित import आदेशों के माध्यम से) लोड करते हैं , तो हमें सामान्य प्रीलोड के बजाय मॉड्यूलप्रो लोड विशेषता का उपयोग करना चाहिए, जो केवल क्लासिक स्क्रिप्ट के लिए अभिप्रेत है।

 <link rel="modulepreload" href="/modules/main.XXXX.mjs"> <link rel="modulepreload" href="/modules/npm.pkg-one.XXXX.mjs"> <link rel="modulepreload" href="/modules/npm.pkg-two.XXXX.mjs"> <link rel="modulepreload" href="/modules/npm.pkg-three.XXXX.mjs"> <!-- ... --> <script type="module" src="/modules/main.XXXX.mjs"></script>

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

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

प्रीलोडिंग के लिए मॉड्यूल की एक सूची बनाना

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

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

 {  generateBundle(options, bundle) {    //         .    const modulepreloadMap = {};    for (const [fileName, chunkInfo] of Object.entries(bundle)) {      if (chunkInfo.isEntry || chunkInfo.isDynamicEntry) {        modulepreloadMap[chunkInfo.name] = [fileName, ...chunkInfo.imports];      }    }    //  -   ...    console.log(modulepreloadMap);  } }

यहाँ, उदाहरण के लिए, मैंने philipwalton.com के लिए और मेरे डेमो आवेदन के लिए एक मॉड्यूलप्रोडक्ट सूची कैसे बनाई है, जिसके बारे में हम नीचे बात करेंगे।

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

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

उत्पादन में वास्तविक मॉड्यूल क्यों तैनात करें?

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

Code कोड की कुल राशि को कम करना

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

▍ बेहतर प्रीलोड कोड

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

परिणामस्वरूप, अनुप्रयोग कोड को टुकड़ों में किस आकार में विभाजित किया गया है, इसकी परवाह किए बिना, आयात script और modulepreload लोड करने की तुलना में सामान्य script टैग और सामान्य preload विशेषता का उपयोग करके लोड करने की तुलना में इन टुकड़ों को डाउनलोड करने के लिए यह बहुत अधिक उत्पादक होगा (विशेषकर यदि संबंधित टैग उत्पन्न होते हैं) गतिशील रूप से और रनटाइम पर DOM में जोड़ा जाता है)।

दूसरे शब्दों में, कुछ प्रोजेक्ट कोड का एक रोलअप बंडल, जिसमें 20 मॉड्यूल टुकड़े होते हैं, उसी प्रोजेक्ट के बंडल की तुलना में तेज़ी से लोड होंगे, जिसमें वेबपैक द्वारा तैयार 20 क्लासिक स्क्रिप्ट टुकड़े शामिल हैं (वेबपैक का उपयोग करने के कारण नहीं, लेकिन क्योंकि ये असली मॉड्यूल नहीं हैं)।

Of कोड के भविष्य के फोकस में सुधार

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

यहाँ कुछ सबसे दिलचस्प नए ब्राउज़र फीचर्स हैं जो विशेष रूप से मॉड्यूल पर ध्यान केंद्रित करते हैं:

विरासत ब्राउज़र समर्थन

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

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

यदि हम उन ब्राउज़रों के बारे में बात करते हैं जो बिल्कुल मॉड्यूल का समर्थन नहीं करते हैं, तो, उनके साथ काम को व्यवस्थित करने के लिए, आप मॉड्यूल / नामांकित पैटर्न का उपयोग कर सकते हैं।

▍Operating उदाहरण

चूंकि इसे प्राप्त करने की तुलना में क्रॉस-ब्राउज़र संगतता के बारे में बात करना हमेशा आसान होता है, मैंने एक डेमो एप्लिकेशन बनाया जो ऊपर चर्चा की गई तकनीकों का उपयोग करता है।

यह एप्लिकेशन एज 18 और फ़ायरफ़ॉक्स ईएसआर जैसे ब्राउज़रों में काम करता है, जो डायनेमिक import() कमांड का समर्थन नहीं करते हैं। इसके अलावा, यह इंटरनेट एक्सप्लोरर 11 जैसे ब्राउज़रों में काम करता है, जो मॉड्यूल का समर्थन नहीं करते हैं।

यह दिखाने के लिए कि यहां चर्चा की गई रणनीति न केवल सरल परियोजनाओं के लिए उपयुक्त है, मैंने इस एप्लिकेशन में कई विशेषताओं का उपयोग किया है जो आज बड़ी परियोजनाओं में आवश्यक हैं:

बाबेल (JSX सहित) का उपयोग कर कोड परिवर्तन।
कॉमनजेएस निर्भरता (जैसे प्रतिक्रिया और प्रतिक्रिया-डोम)।
सीएसएस निर्भरता।
संसाधन हाशिंग
कोड जुदाई
गतिशील आयात (पॉलीफ़िल के रूप में एक वापसी के साथ)।
मॉड्यूल / नामांकित पैटर्न का कार्यान्वयन।

प्रोजेक्ट कोड GitHub पर पाया जा सकता है (अर्थात, आप रिपॉजिटरी को कांटा कर सकते हैं और प्रोजेक्ट को स्वयं बना सकते हैं), डेमो संस्करण ग्लिच पर होस्ट किया गया है, जो आपको इसके साथ प्रयोग करने की अनुमति देता है।

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

परिणाम

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

परियोजना में मॉड्यूल को लागू करने के लिए आपके द्वारा उठाए जाने वाले कदमों की एक संक्षिप्त जानकारी इस प्रकार है:

आउटपुट प्रारूपों के बीच एक बंडल का उपयोग करें, जिसके द्वारा ES2015 मॉड्यूल हैं।
आक्रामक रूप से कोड पृथक्करण (यदि संभव हो तो, node_modules से निर्भरता के आवंटन के लिए अलग टुकड़ों में)।
उन सभी मॉड्यूल को प्रीलोड करें जो आपके स्टैटिक डिपेंडेंसी ट्री ( modulepreload का उपयोग modulepreload ) में हैं।
उन ब्राउज़र के लिए पॉलीफ़िल का उपयोग करें जो डायनेमिक import() स्टेटमेंट का समर्थन नहीं करते हैं।
मॉड्यूल का समर्थन करने वाले ब्राउज़रों के साथ काम को व्यवस्थित करने के लिए मॉड्यूल / नामांकित पैटर्न का उपयोग करें।

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

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

प्रिय पाठकों! क्या आप उत्पादन में जेएस मॉड्यूल का उपयोग करते हैं?

उत्पादन में जावास्क्रिप्ट मॉड्यूल का उपयोग करना: मामलों की वर्तमान स्थिति। भाग २