😻 📁 👩🏿‍🎨 जिम्मेदार जावास्क्रिप्ट विकास भाग 2 ⛵️ ⛹🏿 👨🏾‍💻

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

एक विचार है

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

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

फिर आपने शुरू किया।

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

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

यह आपकी गलती नहीं है।

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

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

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

हम आम समस्याओं से निपटते हैं

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

पेड़ हिल एल्गोरिथ्म लागू करें

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

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

वृक्ष के लिए एल्गोरिथ्म को कुशलता से काम करने के लिए, निम्नलिखित शर्तों को पूरा करना होगा:

एप्लिकेशन कोड और स्थापित पैकेज को ES6 मॉड्यूल के रूप में प्रस्तुत किया जाना चाहिए। CommonJS मॉड्यूल के लिए ट्री शेकिंग एल्गोरिदम का उपयोग करना लगभग असंभव है।
आपका बंडल प्रोजेक्ट के निर्माण के दौरान ES6 मॉड्यूल को किसी अन्य प्रारूप के मॉड्यूल में नहीं बदलना चाहिए। यदि यह टूलकिन में होता है जो Babel का उपयोग करता है, तो @ Babel / present-env में मॉड्यूल होना चाहिए : झूठी सेटिंग। यह ईएस 6 कोड को कॉमनजस का उपयोग करने वाले कोड में परिवर्तित नहीं किया जाएगा।

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

। कोड को भागों में विभाजित करें

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

क्या आप इनपुट बिंदुओं से डुप्लिकेट कोड निकालते हैं?
क्या आप आलसी को वह सब कुछ लोड करते हैं जो गतिशील आयात के साथ इस तरह से लोड किया जा सकता है?

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

बंड बडी टूल वेबपैक संकलन जानकारी की जांच कर सकता है और यह पता लगा सकता है कि आपके बंडलों में समान कोड का कितना उपयोग किया गया है

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

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

विदेशी सर्वर पर स्थित संसाधनों को चिह्नित करने के लिए वेबपैक एक्सटर्नल विकल्प का उपयोग करें

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

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

यदि आप बंडलों से अच्छी तरह से परिचित हैं, तो यह सब आपको सामान्य सत्य लग सकता है। लेकिन मैंने देखा कि कैसे ये चीजें ध्यान नहीं दे रही हैं। इसलिए, उपरोक्त समस्याओं के लिए अपनी परियोजना को दोबारा जांचने के लिए समय न लें।

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

छोटे वैकल्पिक पुस्तकालयों और उपयोगकर्ता प्रणालियों पर ओवरहेड को कम किया

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

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

शायद ऐसा है, लेकिन शायद नहीं। यह प्रयुक्त निर्भरता पर निर्भर करता है। उदाहरण के लिए, रिएक्ट एक अत्यंत लोकप्रिय पुस्तकालय है। लेकिन Preact , React का एक बहुत छोटा विकल्प है, जो डेवलपर को लगभग समान API देता है और कई React ऐड-ऑन के साथ संगत रहता है। Luxon और date-fns क्षणों के विकल्प हैं। js , इस लाइब्रेरी की तुलना में बहुत अधिक कॉम्पैक्ट हैं, जो इतना छोटा नहीं है ।

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

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

स्क्रिप्ट अंतर लोडिंग तकनीकों का उपयोग करें

संभावना है कि बाबेल आपके टूलकिन में हैं। इस उपकरण का उपयोग ES6-compliant स्रोत कोड को कोड में बदलने के लिए किया जाता है जिसे विरासत ब्राउज़र चला सकते हैं। क्या इसका मतलब यह है कि हम उन बड़े बंडलों को भी बर्बाद करने के लिए बर्बाद हो रहे हैं, जिन्हें उन सभी की आवश्यकता नहीं है, जब तक कि सभी पुराने ब्राउज़र बस गायब नहीं हो जाते? बिल्कुल नहीं ! विभेदक संसाधन लोडिंग ES6 कोड के आधार पर दो अलग-अलग असेंबली बनाकर इस समस्या को दरकिनार करने में मदद करता है:

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

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

विरासत ब्राउज़रों के लिए बंडलों का विश्लेषण (बाएं) और नए ब्राउज़रों के लिए बंडलों (दाएं)। बंडल अध्ययन वेबपैक-बंडल-विश्लेषक का उपयोग करके किया गया था। यहाँ इस छवि का पूर्ण आकार संस्करण है।

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

 <!--     : --> <script type="module" src="/js/app.mjs"></script> <!--     : --> <script defer nomodule src="/js/app.js"></script>

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

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

 var scriptEl = document.createElement("script"); if ("noModule" in scriptEl) {  //     scriptEl.src = "/js/app.mjs";  scriptEl.type = "module"; } else {  //     scriptEl.src = "/js/app.js";  scriptEl.defer = true; // type="module"   ,    . } //  ! document.body.appendChild(scriptEl);

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

कॉनवे कम

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

कॉनवे कम

अर्थात् - जो हम बात कर रहे हैं। उदाहरण के लिए, डिफ़ॉल्ट विकल्प ES6 की एक बहुत ही आसान विशेषता है जिसका उपयोग आप पहले से कर रहे हैं:

 function logger(message, level = "log") {  console[level](message); }

यहां यह level पैरामीटर पर ध्यान देने योग्य है, जिसका डिफ़ॉल्ट मान स्ट्रिंग log । इसका मतलब है कि अगर हम logger रैपर फ़ंक्शन का उपयोग करके console.log करना चाहते हैं, तो हमें इस फ़ंक्शन को level पास करने की आवश्यकता नहीं है। सुविधाजनक है, है ना? यह सब अच्छा है - इस फ़ंक्शन को बदलने के दौरान बाबेल को किस कोड को छोड़कर:

 function logger(message) {  var level = arguments.length > 1 && arguments[1] !== undefined ? arguments[1] : "log";  console[level](message); }

यह इस बात का उदाहरण है कि कैसे, इस तथ्य के बावजूद कि हम अच्छे इरादों के साथ नेतृत्व कर रहे हैं, बाबेल ने जो सुख-सुविधाएं दी हैं, वे नकारात्मक परिणाम पैदा कर सकते हैं। स्रोत कोड में बस कुछ ही अक्षर थे जो कार्यक्रम के उत्पादन संस्करण में बहुत लंबे निर्माण में बदल गए। - , , arguments .

, , ? , Babel :

 //   function logger(...args) {  const [level, message] = args;  console[level](message); } //   Babel function logger() {  for (var _len = arguments.length, args = new Array(_len), _key = 0; _key < _len; _key++) {    args[_key] = arguments[_key];  }  const level = args[0],        message = args[1];  console[level](message); }

, Babel @babel/preset-env , . , , , , , ! — «» ( true loose ). — , , , , , . «» , Babel , .

, «» , , Babel :

 // Babel      function logger(message, level) {  console[level || "log"](message); }

, — JavaScript, , . spread , , .

— :

— @babel/runtime @babel/plugin-transform-runtime , , Babel .
, . @babel/polyfill . , babel /preset-env useBuiltins usage .

, , , , , . , JSX , , , . , , . , , . , Babel — . , Babel. , .

: —

, . , JavaScript-, , . , , . - . . , , , , , , , .

, , , , , , , . - — . , , , . . , , , , . , , , .

प्रिय पाठकों! JS-?

जिम्मेदार जावास्क्रिप्ट विकास भाग 2