जावास्क्रिप्ट मॉड्यूल पथ

इस लेखन के समय, जावास्क्रिप्ट में कोई आधिकारिक मॉड्यूलर प्रणाली नहीं थी और सभी ने मॉड्यूल का सर्वोत्तम रूप से अनुकरण किया।

मॉड्यूल या समान संरचनाएं किसी भी वयस्क प्रोग्रामिंग भाषा का एक अभिन्न अंग हैं। यह कोई दूसरा तरीका नहीं है मॉड्यूल आपको दायरे को सीमित करने की अनुमति देता है, आपको आवेदन के कुछ हिस्सों का पुन: उपयोग करने की अनुमति देता है, एप्लिकेशन को अधिक संरचित, शोर से अलग संसाधन और आमतौर पर कोड को अधिक दृश्यमान बनाता है।

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

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

मुझे लगता है कि आपमें से कई लोगों ने AMD, CommonJS & ES हार्मनी के साथ Addy Osmani Writing Modular JavaScript का बेहतरीन लेख पढ़ा है, जो उनकी पुस्तक Learning JavaScript Design Patterns के अध्यायों में से एक बन गया है, यह लेख "आधुनिक" जावास्क्रिप्ट मॉड्यूल के बारे में बात करता है या एक पुराना लेख पढ़ता है JavaScript मॉड्यूल पैटर्न : "पुराने" मॉड्यूल के बारे में गहराई 2010 में।

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

इस लेख में 3 भाग शामिल हैं: मॉड्यूल पाथवे, मॉड्यूल हिम्मत पर मिलान भाग, और सामान्य प्रकार के मॉड्यूल

मॉड्यूल पथ

चरण 1: मॉड्यूल के बिना

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

मॉड्यूल

MyNs.MyModule = function () {}; MyNs.MyModule.prototype = { // ... }; 

सभा

 <script src="myNs.js"/> <script src="myNs/myModule.js"/> 

मेरे आवेदन की प्रगति ने एक और आधा कदम आगे बढ़ाया जब मैंने बिल्ली का उपयोग करके अपनी फ़ाइलों को इकट्ठा करना शुरू किया

 $ cat js/*.js > build.js 

स्टेज 2: प्रीप्रोसेसिंग

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

 if (typeof MyNamespace === 'undefined') { var MyNamespace = {}; } 

और अतिरिक्त स्क्रिबल:

 new MyNamespace.MyConstructor(MyNamespace.MY_CONST); // vs new MyConstructor(MY_CONST); 

और उस समय के मंत्रियों ने इस कोड को अच्छी तरह से संकुचित नहीं किया:

 new a.MyConstructor(a.MY_CONST); // vs new a(b); 

मेरे मॉड्यूल्स ने थोड़ा सा आगे बढ़ाया जब मैंने कुल अलगाव को लागू करना शुरू कर दिया और इसे एक गुंजाइश के साथ प्रतिस्थापित करते हुए नाम स्थान को फेंक दिया। और उसने इन मॉड्यूल का उपयोग करना शुरू किया:

 include('deps/dep1.js'); var MyModule = (function () { var MyModule = function () {}; MyModule.prototype = { // ... }; return MyModule; })(); 

और ऐसी सभा

 (function () { include('myModule.js'); }()); 

और वही प्रीप्रोसेसिंग

 $ includify builds/build.js index.js 

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

स्टेज 3: एएमडी

एक दिन, Reddit को पढ़ते हुए, मैं AMD और आवश्यकता के बारे में एक लेख भर आया।

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

यह था

 YUI().use('dep1', function (Y) { Y.dep1.sayHello(); }); 

बन गया है

 require(['dep1'], function (dep1) { dep1.sayHello(); }); 

एएमडी से परिचित, मुझे एहसास हुआ कि इस समय तक मैंने सब कुछ गलत किया था। केवल 2 कार्यों की require() और define() और मेरी सभी समस्याओं का समाधान किया गया है! मॉड्यूल ने अपनी निर्भरता खुद लोड करना शुरू कर दिया, निर्यात और आयात दिखाई दिया। मॉड्यूल को 3 भागों (आयात, निर्यात, मॉड्यूल बॉडी) में विभाजित किया गया था, जिसे आसानी से समझा जा सकता है। यह उन संसाधनों को खोजने में भी आसान हो गया है जिनकी उन्हें आवश्यकता है और जो वे निर्यात करते हैं। कोड संरचित और क्लीनर बन गया है!

मॉड्यूल

 define('myModule', ['dep1', 'dep2'], function (dep1, dep2) { var MyModule = function () {}; MyModule.prototype = { // ... }; return MyModule; }); 

सभा

 $ node r.js index.js bundle.js 

लेकिन इतना सरल नहीं ...

स्टेज 4: एएमडी में निराशा

मैंने जो ऊपर दिखाया वह एक आदर्श मॉड्यूल और सही संयोजन है। यह एक वास्तविक परियोजना में नहीं होता है। और ऐसा होता है कि एक मॉड्यूल में बहुत अधिक निर्भरता होती है। तो यह कुछ इस तरह से बदल जाता है:

 require(['deps/dep1', 'deps/dep2', 'deps/dep3', 'deps/dep4', 'deps/dep5', 'deps/dep6', 'deps/dep7'], function ( dep1, dep2, dep3, dep4, dep5, dep6, dep7) { return function () { return dep1 + dep2; }; }); 

आप इस मॉड्यूल का उपयोग कर सकते हैं, लेकिन इसके साथ बहुत अधिक उपद्रव। इस समस्या को दूर करने के लिए, आप सरलीकृत कॉमनजेएस पर इस तरह के एक मॉड्यूल का रीमेक कर सकते हैं। इस मामले में भी, आपको एक define() आवरण लिखना नहीं है और ईमानदार CommonJS मॉड्यूल बनाना है, और फिर उन्हें r.js का उपयोग करके r.js

 define(function (require, module, exports) { var dep1 = require('dep1'), dep2 = require('dep2'), dep3 = require('dep3'), dep4 = require('dep4'), dep5 = require('dep5'), dep6 = require('dep6'), dep7 = require('dep7'); return function () { return dep1 + dep2; }; }); 

आवश्यकताएँ के लिए सरलीकृत कॉमनजस प्रारूप "मूल नहीं" है, बस डेवलपर को इसे बनाना था। यदि आप ऐसे मॉड्यूल लिखना शुरू करते हैं, तो आवश्यकताएँ इस नियमित रूप से इस मॉड्यूल की निर्भरता की तलाश करना शुरू कर देंगी।



और शायद कुछ नहीं मिला:

 require("myModule//"); require("my module"); require("my" + "Module"); var require = r; r("myModule"); 

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

जरूर, इसके लिए एक समाधान की आवश्यकता है - विन्यास में इस तरह के प्रत्येक मॉड्यूल को पंजीकृत करें:

 ({ "paths": { "myModule": "modules/myModule.js" } }) 

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

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

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

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

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

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

 require(['async!i18n/data', 'pewpew.js', 'text!templates/index.html'], fucntion (data, pewpew, template) { }); 

परियोजनाओं में जहां संसाधन नीरस हैं या बहुत अधिक संसाधन नहीं हैं - यह लगभग हो सकता है।

चरण 5: मॉड्यूल के लिए खोजें

मुझे एहसास हुआ कि आप अब उस तरह नहीं रह सकते ... लेकिन मुझे पता था कि मुझे क्या चाहिए:

1 मॉड्यूल कॉमनजस होना चाहिए

जब आप Node.js और JS @ DOM के तहत एक ही मॉड्यूल चलाने की आवश्यकता होती है, तो एक बहुत ही लगातार मामला। अक्सर ये कुछ ऐसे मॉड्यूल्स होते हैं जो बाहरी वातावरण (फाइल सिस्टम / DOM) से जुड़े नहीं होते हैं या इसके कुछ हिस्सों को अलग किया जाता है: टेम्प्लेट (सबसे सामान्य हिस्सा), समय के साथ काम करने के कार्य, फ़ार्मेटिंग फ़ंक्शंस, स्थानीयकरण, सत्यापनकर्ता ...

जब आप एएमडी लिखते हैं और आपको कुछ फिर से उपयोग करने की आवश्यकता होती है तो आपके पास 2 तरीके होते हैं: एएमडी को सीजेएस को फिर से लिखना या नोड-आवश्यकता का उपयोग करना। अधिक बार वे दूसरा विकल्प चुनते हैं क्योंकि कुछ भी बदलने की आवश्यकता नहीं है। लेकिन। तब एक मॉड्यूलर मेस दिखाई देता है, जो Node.js. में एक मौजूदा मॉड्यूल लोडिंग सिस्टम पर एक अजीब अमूर्तता है मैं वास्तव में Node.js. में AMD मॉड्यूल को पसंद नहीं करता था

CJS, Node.js के साथ संगतता के अलावा, define() आवरण और फ़ंक्शन निकाय को प्रारूपित करने वाले अतिरिक्त इंडेंट से वंचित है। इसकी आवश्यकता और निर्यात दृश्य और ईएस 6 मॉड्यूल के मुकाबले अधिक दृश्य और करीब define() । अपने लिए तुलना करें:

ES6 मॉड्यूल

 import "dep1" as dep1; import "dep2" as dep2; export var name = function () { return dep1 + dep2; }; 

कॉमनजेएस / मॉड्यूल

 var dep1 = require("dep1"), dep2 = require("dep2"); exports.name = function () { return dep1 + dep2; }; 

एएमडी

 require(['dep1', 'dep2'], function (dep1, dep2) { return { name: function () { return dep1 + dep2; } }; }); 

और अगर ऐसा होता है कि मुझे एएमडी पर लौटना है, तो यह बिल्कुल भी चोट नहीं पहुंचाएगा - मुझे केवल एक लाइन को रजिस्टर करने की आवश्यकता होगी ताकि r.js मेरे CJS मॉड्यूल को लपेटे।

2 मॉड्यूल बिल्डर

आज सब कुछ चल रहा है, भले ही आप कॉफ़ीस्क्रिप्ट न लिखें, फिर भी आप किसी तरह अपनी स्क्रिप्ट की जांच, संग्रह, संपीड़ित करते हैं।

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

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

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

3 लचीले विन्यास प्रणाली: निर्भरता, विरासत, मिश्रण

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

उदाहरण के लिए, एक prod विन्यास है, dev विन्यास उससे विरासत में मिला है और कुछ मॉड्यूल को बदल देता है। वहाँ भी हैं ru और en , जो हम prod+en , dev+ru । अब, किसी भी "सामान्य" और कॉपी-पेस्ट ( prod-ru , prod-en , dev-ru , dev-en ) के बजाय हमारे पास केवल 4 "सूखी" कॉन्फिग फाइलें हैं: prod , dev , ru , en ।

4 सीएलआई

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

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

तुलना

 $ tool make -f path/to/build_name.js -o path/to/build.js 

और

 $ tool make build_name 

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

चरण 6: ब्राउज़र करें

Browserify एक ऐसा टूल है जो आपको किसी भी Node.js मॉड्यूल को ब्राउजर में चलाने की अनुमति देता है।

बस browserify main.js > bundle.js और यह काम करता है।

थोड़ी देर तक ब्राउजर के साथ काम करने के बाद, मुझे इसके वास्तविक उपयोग-मामले का एहसास हुआ: ब्राउज़र में काम करने के लिए Node.js वातावरण को अपनाना। ब्राउजर अपने उद्देश्यों के लिए बहुत अच्छा है, लेकिन उन वास्तविकताओं के लिए नहीं जिनमें वेब एप्लिकेशन बनाए जाते हैं। जब गैर-अनुकूलित तृतीय-पक्ष मॉड्यूल होते हैं, जब एप्लिकेशन के बड़े हिस्से का एक गतिशील लोड होता है। मुझे कंसोल में बहुत कुछ करना था ताकि सब कुछ काम कर सके।

स्टेज 7: एलएमडी

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

नतीजतन, एक उपकरण विकसित किया गया था जो मेरी परियोजनाओं के स्क्रिप्ट भाग को इकट्ठा करने में लगा हुआ था।

यहाँ कुछ विशेषताएं हैं जो LMD को रेखांकित करती हैं:

विन्यास से 1 विधानसभा

चूंकि एक विन्यास की उपस्थिति अपरिहार्य है, तो उस पर निर्माण क्यों नहीं किया जा सकता है? Lmd का व्यवहार पूरी तरह से उस विन्यास से निर्धारित होता है जिसमें मॉड्यूल और प्लगइन्स और परिणामी फ़ाइल के निर्यात पथ दोनों होते हैं। कन्फ़िगल्स को विरासत में मिलाया जा सकता है और अन्य कॉन्फ़िगरेशन के साथ मिलाया जा सकता है।

यह वही है जो विन्यास जैसा दिखता है

 { "name": "My Config", "root": "../js", "output": "../build.lmd.js", "modules": { "main": "index.js" }, "optimize": true, "ie": false, "promise": true } 

यदि आपके पास सौ मॉड्यूल हैं - तो आपको कॉन्फ़िगरेशन में प्रत्येक मॉड्यूल को पंजीकृत करने की आवश्यकता नहीं है! यह एक ही प्रकार के मॉड्यूल के लिए "पुनर्लेखन नियम" दर्ज करने के लिए पर्याप्त है।

 { "modules": { "main": "index.js", "<%= file %>Template": "templates/*.html" } } 

और चरम मामलों में, आप सीजेएस मॉड्यूल के रूप में एक विन्यास लिख सकते हैं और मक्खी पर सब कुछ उत्पन्न कर सकते हैं।

2 सार एफएस: फाइल सिस्टम के लिए बाध्यकारी की कमी

एक ओर FS को बाइंड करना स्वाभाविक है और HTTP सर्वर फ़ाइल सिस्टम को विशिष्ट रूप से प्रतिबिंबित कर सकता है। लेकिन यह याद रखने योग्य है कि ब्राउज़र में फ़ाइल सिस्टम नहीं है और HTTP सर्वर संसाधनों की आपूर्ति करता है, और कोड पहले से ही समझता है कि इस URL का पाठ एक मॉड्यूल है। संसाधनों को मनमाने नामों के तहत सीडीएन पर ले जाया जा सकता है।

एक सार फ़ाइल सिस्टम की शुरूआत मॉड्यूल पर अमूर्तता की अनुमति देती है। उदाहरण के लिए, आपके पास एक लोकल मॉड्यूल है जिसके तहत locale.ru.json और locale.en.json दोनों को इस तथ्य के कारण छिपाया जा सकता है कि इन मॉड्यूल का इंटरफ़ेस समान है, हम पारदर्शी रूप से एक फ़ाइल को दूसरे में बदल सकते हैं।

आप अपने मॉड्यूल का नाम रखने के लिए स्वतंत्र हैं और रिश्तेदार रास्तों के बारे में सोचे बिना कनेक्ट करें। यदि आपके पास कई मॉड्यूल हैं और आप भूल गए हैं कि इस मॉड्यूल के तहत कौन सी फ़ाइल छिपाई गई है, तो आपको बस lmd info का उपयोग करने की आवश्यकता है:

 $ lmd info build_name | grep module_name info: module_name ✘ plain ✘ ✘ ✘ info: module_name <- /Users/azproduction/project/lib/module_name.js 

3 अधिभार की आवश्यकता नहीं है () और प्लगइन्स

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

प्लगइन्स को स्पष्ट रूप से कॉन्फ़िगरेशन में लिखे जाने की आवश्यकता होती है, हालांकि LMD आपको "सही कोड" लिखने पर प्लगइन को सक्षम करने में याद रखने में मदद करेगा।

उदाहरण के लिए, इस कोड में एलएमडी 3 प्लगइन्स को नहीं भूलने में मदद करेगा: सीएसएस, समानांतर और वादा

 require.css(['/pewpew.css', '/ololo.css']).then(function () { }); 

लेकिन इस कोड में, केवल जेएस प्लगइन

 var js = require.js; js('http://site.com/file.js').then(function () { }); 

आप इनहेरिटेंस और मिक्स कॉन्फ़िगरेशन का उपयोग करके प्लग इन को सक्षम और अक्षम कर सकते हैं।

4 एडाप्टिंग मॉड्यूल

ऐसा होता है कि परियोजना में कुछ फाइलें हैं जो मॉड्यूल को कॉल करना मुश्किल है, लेकिन उन्हें अन्य मॉड्यूल की तरह उपयोग करने की आवश्यकता है। LMD आसानी से किसी भी फ़ाइल को अनुकूलित कर सकती है और बिल्ड समय पर CJS मॉड्यूल बना सकती है। इसके अलावा, पाठ फ़ाइलों (टेम्प्लेट) और JSON फ़ाइलों का उपयोग करने के लिए, आपको किसी भी प्लग-इन को पंजीकृत करने की आवश्यकता नहीं है (आवश्यकता के लिए प्लगइन पाठ देखें) या एडेप्टर। उसी आवश्यकता के विपरीत एलएमडी इन फाइलों को ईमानदार मॉड्यूल में बदल देता है, और उन्हें शिम के साथ अनुकूलित नहीं करता है।

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

भविष्य?

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

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

 <script> import {get, Deferred} from "http://yandex.st/jquery/3.0/jquery.min.js"; get('/').then(console.log.bind(console)); </script> 

यह लगभग समान है

 <script src="http://yandex.st/jquery/3.0/jquery.min.js"> <script> var get = $.get, Deferred = $.Deferred; get('/').then(console.log.bind(console)); </script> 

बदले में, लॉक को <script async/> का उपयोग करके हटाया जा सकता है

मॉड्यूल की एक गतिशील लोडिंग है, लेकिन यह अभी सही नहीं है:

 Loader.load('http://json.org/modules/json2.js', function(JSON) { alert(JSON.stringify([0, {a: true}])); }); 

मुझे उम्मीद है कि मॉड्यूल लोडर कई मॉड्यूल की विधानसभा को लोड करने में सक्षम होगा। तब इतना ही काफी होगा।

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

निष्कर्ष

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

materiel

यदि आपने मेरे मॉड्यूलर पथ में महारत हासिल की है, तो मुझे लगता है, आपको मेरे छोटे मॉड्यूलर वर्गीकरण में दिलचस्पी होगी।

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

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

निर्भरता का संकल्प

असेंबली टूल या डेवलपर यह निर्धारित करता है कि इस मॉड्यूल के सामान्य संचालन के लिए किन निर्भरताओं को कनेक्ट करना / आरंभ करना आवश्यक है। निर्भरता, बदले में, निर्भरताएं भी हो सकती हैं।

निर्भरता का संकल्प। मैनुअल नियंत्रण

डेवलपर के कंधों पर निर्भरता प्रबंधन। डेवलपर विश्लेषणात्मक रूप से समझता है कि किन निर्भरताओं को जोड़ने की आवश्यकता है।

 <script src="deps/dep1.js"/> <script src="deps/dep2.js"/> <script src="moduleName.js"/> 

और तदनुसार main.js

 var moduleName = function () { return dep1 + dep2; }; 

उपयोग करने के लिए कोई तृतीय-पक्ष लाइब्रेरी नहीं
जब कई मॉड्यूल नहीं होते हैं और वे सभी अपने होते हैं, तो यह ठीक है
जब कई मॉड्यूल होते हैं, तो ऐसे कोड का समर्थन नहीं किया जा सकता है।
एकाधिक फ़ाइलें = एकाधिक सर्वर अनुरोध

"जल्दी भरने के लिए उपयुक्त"।

निर्भरता का संकल्प। निर्भरताएँ विन्यास में लिखी जाती हैं

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

LMD में इस config का उपयोग किया जाता है

 { "modules": { "main": "moduleName.js" "<%= file %>": "deps/*.js" } } 

और तदनुसार main.js

 var dep1 = require('dep1'), dep2 = require('dep2'); module.exports function () { return dep1 + dep2; }; 

मॉड्यूल फ़ाइल सिस्टम से बंधे नहीं हैं (आप किसी भी फ़ाइल को कोई भी नाम दे सकते हैं)
मॉड्यूल का नाम बदले बिना, आप इसकी सामग्री को बदल सकते हैं
ऐसे कॉन्फ़िगरेशन को लिखना आवश्यक है। एक
अतिरिक्त टूल / लाइब्रेरी की आवश्यकता है।

निर्भरता का संकल्प। निर्भरताएँ मॉड्यूल में ही लिखी जाती हैं

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

यह विधि AMD (आवश्यकताएँ) का उपयोग करती है

 require(['deps/dep1', 'deps/dep2'], function (dep1, dep2) { return function () { return dep1 + dep2; }; }); 

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

विकृतियों

 require(['deps/dep1', 'deps/dep2', 'deps/dep3', 'deps/dep4', 'deps/dep5', 'deps/dep6', 'deps/dep7'], function ( dep1, dep2, dep3, dep4, dep5, dep6, dep7) { return function () { return dep1 + dep2; }; }); 

कॉमन जेएसएस में गिरावट

 define(function (require, module, exports) { var dep1 = require('dep1'), dep2 = require('dep2'), dep3 = require('dep3'), dep4 = require('dep4'), dep5 = require('dep5'), dep6 = require('dep6'), dep7 = require('dep7'); return function () { return dep1 + dep2; }; }); 

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

ऐसे मामले हैं जब उसी तरह से एक विन्यास लिखना आवश्यक है, उदाहरण के लिए, कुछ पुराने मॉड्यूल को अनुकूलित करने के लिए जो परिभाषित करना नहीं जानता है या यदि किसी प्रकार का "ईमानदार मॉड्यूल" गतिशील रूप से आरंभिक है - require('templates/' + type)और नियमित इसे नहीं ढूंढ सकता है। डायनामिक इनिशियलाइज़ेशन एक दुर्लभ चीज़ है और इसका उपयोग मुख्य रूप से टेम्प्लेट के डायनामिक लोडिंग के लिए किया जाता है, लेकिन यह संभव है।

लगभग सभी निर्भरताएँ फ़ाइल में ही बताई गई हैं।
कन्फ़िगल्स को एसिंक्रोनस रूप से लोड किया गया है।
कोई विन्यास लिखने की आवश्यकता नहीं है
लेकिन कभी-कभी आपको वैसे भी कॉन्फिग लिखना होगा। एक
अतिरिक्त टूल / लाइब्रेरी की आवश्यकता है

निर्भरता का संकल्प। निर्भरताएं मॉड्यूल और कॉन्फ़िगरेशन में पंजीकृत हैं

निर्भरताएं फ़ाइल के साथ और एक विशेष कॉन्फ़िगरेशन में पंजीकृत हैं।

निर्भरता को हल करने के लिए किसी भी पैकेज प्रबंधक द्वारा कॉन्फ़िगरेशन का उपयोग किया जाता है। उदाहरण के लिए npm औरpackage.json

 { "dependencies": { "express": "3.x", "colors": "*" } } 

और तदनुसार main.js

 //   var express = require('express'); //   var dep1 = require('./deps/dep1'), dep2 = require('./deps/dep2'); module.exports function () { return dep1 + dep2; }; 

डेवलपर निर्भरता और उनके संस्करणों की एक सूची को परिभाषित करता है। पैकेज मैनेजर मॉड्यूल और उनकी निर्भरता को लोड करता है। यहां, सिद्धांत रूप में, विकल्पों के बिना, प्रबंधक को मॉड्यूल के बारे में कुछ भी नहीं पता है। package.jsonप्रबंधक के लिए, केवल इंटरैक्शन इंटरफ़ेस। बदले में, प्रत्येक मॉड्यूल फ़ाइल सिस्टम से सीधे इसके हिस्सों को डाउनलोड कर सकता है। require('pewpew.js')

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

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

निर्भरता पहुंच

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

निर्भरता तक पहुंच। मनमाना

सभी मॉड्यूल वैश्विक दायरे में या नाम स्थान पर खुले रूप से झूठ बोलते हैं। प्रत्येक मॉड्यूल, बिना किसी प्रतिबंध के, कहीं भी किसी भी तरह से आवेदन के किसी भी हिस्से तक पहुंच सकता है।

 var dep1 = 1; var dep2 = 2; alert(dep1 + dep2); 

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

निर्भरता तक पहुंच। गतिशील

मॉड्यूल तक पहुंच केवल "लोडर" के माध्यम से प्राप्त की जा सकती है - require()या मॉड्यूल की निर्भरता की घोषणा करके define()

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

 var dep1 = require('./deps/dep1'), dep2 = require('./deps/dep2'); alert(dep1 + dep2); 

तदनुसार, विधि के साथ define()

 require(['./deps/dep1', './deps/dep2'], function (dep1, dep2) { alert(dep1 + dep2); }); 

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

निर्भरता तक पहुंच। निवेदक

कोड लिखते समय मॉड्यूल घोषित किए जाते हैं और गतिशील रूप से लोड नहीं होते हैं। एक स्थिर कोड विश्लेषक स्पष्ट रूप से समझ सकता है कि एप्लिकेशन के काम करने के लिए मॉड्यूल का कौन सा सेट आवश्यक है। लगभग सभी आयात निर्माण इस तरह से काम करते हैं।

 import * from "dep1"; import * from "dep2"; 

इसके अलावा निर्भरता तक पहुंच की इस पद्धति के तहत जिम्मेदार ठहराया जा सकता है और स्थिर एएमडी परिभाषित ()

 define('module', ['./deps/dep1', './deps/dep2'], function (dep1, dep2) { }); 

स्टेटिक आयात कलेक्टरों को निर्भरता का निर्माण करने की अनुमति देता है, और ES3- संगत मॉड्यूल ES3- संगत में कोड रीमेक करने की अनुमति देता है।

स्थैतिक विश्लेषण संभव (पूर्ण या आंशिक)
ES6 मॉड्यूल अनुवाद संभव
शुद्ध रूप में शायद ही कभी लागू होता है

मॉड्यूल से निर्यात करें

अधिकतर, मॉड्यूल कुछ संसाधन प्रदान करते हैं जो अन्य मॉड्यूल का उपयोग कर सकते हैं। यह डेटा, उपयोगिताओं (दिनांक, संख्या, i18n, आदि का प्रारूप) हो सकता है। एक मॉड्यूल से निर्यात यह निर्धारित करता है कि मॉड्यूल कैसे कहता है "मैं ऐसे और ऐसे संसाधन प्रदान कर रहा हूं।"

निर्यात। अराजक निर्यात

मॉड्यूल कहीं भी, कभी भी, कुछ भी निर्यात करता है

 var a = 10, b = ''; for (var i = 0; i < a; i++) { b += i; } var dep1 = b; 

हेल के वैश्विक दायरे और एक बुरे सपने को रोकना, किसी भी मामले में यह सिद्धांत रूप में समर्थित नहीं है

निर्यात। मजबूत प्रबंधित निर्यात

यदि हम IIFE को जोड़कर पिछली पद्धति को थोड़ा संशोधित करते हैं, तो हमें यह विधि मिल जाएगी। मॉड्यूल पहले से जानता है कि यह कहां झूठ होगा और इसे क्या कहा जाएगा।

 var dep1 = (function () { var a = 10, b = ''; for (var i = 0; i < a; i++) { b += i; } return b; })(); 

या थोड़ा अलग विकल्प

 (function () { var a = 10, b = ''; for (var i = 0; i < a; i++) { b += i; } exports.dep1 = b; })(exports); 

या एएमडी नाम दिया है

 define('dep1', [], function () { var a = 10, b = ''; for (var i = 0; i < a; i++) { b += i; } return b; }); 

यह सरल है।
ऐसे मॉड्यूल को बनाने और उपयोग करने के लिए किसी विशेष उपकरण की आवश्यकता नहीं होती है (केवल AMD को छोड़कर)।
केवल आवश्यक निर्यात किया जाता है।
मॉड्यूल जानता है कि यह कहां निर्यात किया जाता है और इसका क्या नाम होगा।

निर्यात। "स्व-निर्यात" एक सख्त नाम के साथ

यह विधि "एक मॉड्यूल के पंजीकरण" के विशेष कार्य पर आधारित है ready(), जिसे तैयार होने पर मॉड्यूल को कॉल करना चाहिए। यह 2 तर्क लेता है - मॉड्यूल का नाम और संसाधन जो इसे प्रदान करता है।

 (function () { var a = 10, b = ''; for (var i = 0; i < a; i++) { b += i; } ready('dep1', b); })(); 

इस तरह के एक मॉड्यूल की निर्भरता लोड करने के लिए, के load()समान एक फ़ंक्शनrequire()

 load('dep1', 'dep2', function (dep1, dep2) { ready('dep3', function () { return dep1 + dep2; }); }); 

 load('dep3', do.stuff); 

मॉड्यूल को एसिंक्रोनस रूप से निर्यात किया जाता है और इसके निर्यात में देरी कर सकता है।
मॉड्यूल को पता नहीं है कि यह कहां झूठ होगा।
मॉड्यूल खुद को निर्यात किया जाता है (मॉड्यूल इसका उपयोग करने वाले मॉड्यूल को मात देता है)।
मॉड्यूल को इसका नाम पता है और इसे गतिशील रूप से बदल सकता है।
मॉड्यूल को कई मॉड्यूल पंजीकृत कर सकते हैं।
एक विशेष पुस्तकालय की आवश्यकता है।

निर्यात। कस्टम नामांकित निर्यात

मॉड्यूल न तो अपना नाम जानता है और न ही यह झूठ होगा। मॉड्यूल का उपभोक्ता स्वयं निर्धारित करता है कि उपभोक्ता के संदर्भ में मॉड्यूल को क्या कहा जाएगा।

यह CommonJS मॉड्यूल है

 var a = 10, b = ''; for (var i = 0; i < a; i++) { b += i; } module.exports = b; 

या अनाम एएमडी

 define([], function () { var a = 10, b = ''; for (var i = 0; i < a; i++) { b += i; } return b; }); 

हम मॉड्यूल निर्यात के दौरान किसी भी नाम का उपयोग कर सकते हैं।

 var dep1 = require('deps/dep1'); 

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

निर्यात। ईमानदार आयात / निर्यात

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

हम मॉड्यूल की घोषणा करते हैं।

 module "deps" { var a = 10, b = ''; for (var i = 0; i < a; i++) { b += i; } export var dep1 = b; export var dep2 = b + 1; } 

आप बाध्यकारी के बिना एक मॉड्यूल भी घोषित कर सकते हैं module {}।

आप डिफ़ॉल्ट नामों का उपयोग कर सकते हैं और कम लिख सकते हैं

 import * from "deps"; console.log(dep1); 

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

 import "crypto" as ns; console.log(ns.dep1); 

आप मॉड्यूल का हिस्सा निर्यात कर सकते हैं

 import {dep1} from "deps"; console.log(dep1); 

कई भाषाओं से परिचित आयात - परिचित और दृश्य।
यह ECMAScript 6.
आपको ES6 मॉड्यूल को ES3- संगत कोड में अनुवाद करने की आवश्यकता है, उदाहरण के लिए, टाइपस्क्रिप्ट से मॉड्यूल का उपयोग करें

साइड मॉड्यूल

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

बिना विधानसभा के

HTML में सब कुछ

 <script src="deps/dep1.js"/> <script src="deps/dep2.js"/> <script src="moduleName.js"/> 

यह सरल है।
जब मॉड्यूल की संख्या बढ़ जाती है, तो अनुप्रयोग समर्थित होना बंद हो जाता है और अनुरोधों की संख्या में वृद्धि के कारण धीमा होना शुरू हो जाता है।
HTML संस्थाओं और मॉड्यूल घोषणा को मिलाते हुए।
नई विधानसभा - नई। Html

मॉड्यूल की विधानसभा। फ़ाइलों का मुखौटा

हम जमा करते हैं

 $ cat **/*.js > build.js 

उपयोग

 <script src="build.js"/> 

यह काफी सरल है।
केवल 1 फ़ाइल अपलोड की गई है।
प्रत्येक प्रकार की असेंबली के लिए, आपको नई स्क्रिप्ट बनाने की आवश्यकता है।
फ़ाइलों को किसी भी क्रम में अलग-अलग ओएस और एफएस में इकट्ठा किया जा सकता है ।

मॉड्यूल की विधानसभा। preprocessing

विधि फ़ाइलों में विशेष "टैग" के लिए खोज करना है - include('path/name.js')या // include path/name.jsसमान

 include('deps/dep1.js'); include('deps/dep2.js'); var moduleName = function () { return dep1 + dep2; }; 

यह सब इस प्रारूप में एक विशेष उपयोगिता द्वारा तैनात किया गया है।

 /* start of deps/dep1.js */ var dep1 = 1; /* end of deps/dep1.js */ /* start of deps/dep2.js */ var dep2 = 2; /* end of deps/dep2.js */ var moduleName = function () { return dep1 + dep2; }; 

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

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

में कोड का इंजेक्शन संभव है। मॉड्यूल में कोड का इंजेक्शन अखंडता का उल्लंघन करता है। मॉड्यूल, "use strict"नाम संघर्ष और अन्य परेशानियों के साथ समस्याओं को जोड़ता है ।

यहाँ एक विशिष्ट उदाहरण है

 (function () { "use strict"; var i = 3; include('dep1'); //     return dep1 + i; })(); 

और उसका नशा

 var i = 4, dep = 01234; 

मुझे लगता है कि आप परिणामों को समझते हैं ;-)

मॉड्यूल की विधानसभा। स्थैतिक निर्भरता विश्लेषण

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

उदाहरण के लिए, ऐसा मॉड्यूल

 require(['dep1', 'dep2'], function (dep1, dep2) { return function () { return dep1 + dep2; }; }); 

यदि आप इसे r.js के माध्यम से चलाते हैं तो इसे इस रूप में यहाँ फिर से बनाया जाएगा

 define('dep1', [], function () { return 1; }); define('dep2', [], function () { return 2; }); require(['dep1', 'dep2'], function (dep1, dep2) { return function () { return dep1 + dep2; }; }); 

browserify एक समान तरीके से बर्ताव करता है, लेकिन एकत्र अधिक जटिल प्रारूप

केवल 1 फ़ाइल जा रहा
सभी निर्भरता मॉड्यूल में पंजीकृत हैं
विधानसभा एक नई फ़ाइल बनाना या सिमलिंक के साथ जादू करने के लिए आवश्यक है के प्रत्येक प्रकार के लिए
पूर्वप्रक्रमक कुछ निर्भरता नहीं मिल सकता है (गतिशील मॉड्यूल नामों से निर्माण)
पूर्ववर्ती पैरा को ठीक करने के इन मॉड्यूल को सक्षम करने के लिए आपको एक विन्यास लिखना होगा

साइड मॉड्यूल। असेंबली को कॉन्फ़िगर करें

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

यह विधि LMD का उपयोग करती है।

 { "root": "../js", "modules": { "main": "main.js", "dep1": "deps/dep1.js", "dep2": "deps/dep2.js" } } 

विकल्प, ज़ाहिर है, दिलचस्प है, लेकिन मॉड्यूल और कॉन्फ़िगरेशन में एक ही चीज़ लिखने के लिए 2 बार क्यों?

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

यह कॉन्फ़िगरेशन पिछले एक के समान है।

 { "root": "../js", "modules": { "<%= file %>": "**/*.js" } } 

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

 { "root": "../js", "modules": { "<%= file %><%= dir[0][0].toUpperCase() %><%= dir[0].slice(1, -1) %>": "{controllers,models,views}/*.js" } } 

इस पद्धति के परिणाम निम्नानुसार हैं:

नेत्रहीन - पूरे प्रोजेक्ट ट्री को एक फ़ाइल में वर्णित किया जा सकता है
विश्वसनीय - विश्लेषक त्रुटियों को बाहर रखा गया है
सार फ़ाइल सिस्टम
को कॉन्फ़िगर करने की
आवश्यकता है कलेक्टर की आवश्यकता है

मॉड्यूल आरंभीकरण और व्याख्या

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

फ़ंक्शन को प्रारंभ या व्याख्या नहीं किया जाता है। केवल एक जावास्क्रिप्ट स्ट्रिंग को इनिशियलाइज़ किया जाता है।

 'function a() {return Math.PI;}'; 

फ़ंक्शन को प्रारंभ किया गया है।

 function a() { return Math.PI; } 

फ़ंक्शन को प्रारंभ और व्याख्या किया जाता है।

 function a() { return Math.PI; } a(); 

प्रत्येक फ़ंक्शन की घोषणा और उसके कॉल में कुछ समय लगता है, खासकर मोबाइल पर, इसलिए इस समय को कम करना अच्छा होगा।

स्टार्टअप पर प्रारंभिक और व्याख्या की गई

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

 var dep1 = (function () { var a = 10, b = ''; for (var i = 0; i < a; i++) { b += i; } return b; })(); 

अतिरिक्त टूल का उपयोग करने की आवश्यकता नहीं है।
यदि कोड बड़ा नहीं है, तो आरंभीकरण का समय महत्वपूर्ण नहीं है।
जैसे-जैसे कोड की मात्रा बढ़ती है, स्टार्टअप लेटेंसी दिखाई देने लगती है।

स्टार्टअप पर शुरू में मांग पर व्याख्या की गई

अब एक काफी लोकप्रिय तरीका है, जो Node.js में AMD और मॉड्यूल दोनों द्वारा उपयोग किया जाता है

 define('dep1', [], function () { var a = 10, b = ''; for (var i = 0; i < a; i++) { b += i; } return b; }); 

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

मॉड्यूल के बहुत मजबूत दृश्य बदलने के लिए कोई ज़रूरत नहीं
स्टार्टअप विलंबता काफी कम हो जाता है जब कोड की एक बड़ी राशि
आप अतिरिक्त पुस्तकालय की जरूरत है

अनुरोध पर प्रारंभिक और व्याख्या की गई

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

LMD असेंबली पीस (कॉन्फ़िगर नहीं)

 { 'dep1': '(function(){var a=10,b="";for(var i=0;i<a;i++){b+=i;}return b;})' } 

जब कुछ मॉड्यूल को मॉड्यूल संसाधनों की आवश्यकता होती है dep1, तो LMD इस कोड की व्याख्या और इनिशियलाइज़ करता है।

कुछ इस तरह:

 var resources = new Function('return ' + modules['dep1'])()(require, module, exports); 

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

यह ऑपरेशन डेवलपर के लिए पारदर्शी है। एक
अतिरिक्त पुस्तकालय की
आवश्यकता है।

बाहरी निर्भरता डाउनलोड करें

जैसा कि मैंने पहले ही कहा, जावास्क्रिप्ट @ डोम का अपना वातावरण है, इसलिए लोडिंग मॉड्यूल के लिए सामान्य तरीके यहां काम नहीं करते हैं। मॉड्यूल दूर से झूठ बोलते हैं और उनकी समकालिक लोडिंग वास्तविक नहीं होती है। यदि एक डेस्कटॉप एप्लिकेशन में हम लाइब्रेरी को "प्रकाश की गति से" सिंक्रोनाइज़ कर सकते हैं, तो जावास्क्रिप्ट @ DOM में EventLoop ब्लॉक होने के कारण यह शायद ही वास्तविक हो।

हम एक बार में सब कुछ लोड नहीं कर सकते, इसलिए हमें आविष्कार करना होगा और कुछ भुगतना होगा :)

अप्रबंधित मॉड्यूल लोडर

गैर-निष्पादन योग्य मॉड्यूल द्वारा, मेरा मतलब है कि कोई भी कोड जिसे किसी भी अतिरिक्त प्रसंस्करण की आवश्यकता नहीं है। इस तरह के एक लोडर, उदाहरण के लिए, यह jQuery.getScript(file)

निम्नलिखित की तरह कुछ करता है:

 var script = document.createElement('script'); script.src = file; script.onload = done; document.head.appendChild(script); 

यदि आप एक ही समय में कई मॉड्यूल लोड करते हैं, तो उन्हें लोडिंग के क्रम में निष्पादित किया जाएगा। ऐसा होता है कि आपको सूचीबद्ध किए गए क्रम में मॉड्यूल को निष्पादित करने की आवश्यकता होती है। उदाहरण के लिए, LAB.js लाइब्रेरी, एक ही समय में स्क्रिप्ट कोड को लोड करने के लिए XHR का उपयोग करता है, और फिर उस कोड को क्रमिक रूप से चलाता है। XHR, बदले में, अपनी सीमाओं का परिचय देता है।

 $LAB .script("framework.js").wait() .script("plugin.framework.js"); 

बाकी लोडर, जैसे कि YepNope और script.js, लगभग एक ही काम कर रहे हैं।

सस्ता समाधान
XHR या अतिरिक्त लेखन के हिस्से पर प्रतिबंध हो सकता है

प्रबंधित मॉड्यूल लोडर

कोई भी वयस्क मॉड्यूलर प्रणाली अपने स्वयं के लोडर के साथ आती है और किसी भी मॉड्यूल और उनकी निर्भरता को लोड कर सकती है। उदाहरण के लिए, यह समारोह करता है require()और define()RequireJS की।

आवश्यकताएँ require()जेआरजे से कार्य आवश्यक निर्भरता और निर्भरता निर्भरता को लोड करेगा और निर्दिष्ट क्रम में इन मॉड्यूल के कोड को निष्पादित करेगा।

 require(['dep1', 'dep2'], function (dep1, dep2) { console.log(dep1 + dep2); }); 

उदाहरण के लिए, LMD में, बंडल जैसी कोई चीज होती है - कई मॉड्यूल एक फाइल में इकट्ठे होते हैं। इस बंडल को लोड करते समय, इसके सभी मॉड्यूल किसी भी मॉड्यूल के लिए उपलब्ध हो जाते हैं।

 _e4fg43a({ 'dep1': function () { return 1; }, 'dep2': 2, 'string': 'Hello, <%= name %>!' }); 

 require.bundle('name').then(function () { // do stuff }); 

मॉड्यूल लोडिंग और उनके प्रारंभ दोनों का प्रबंधन;
डेवलपर के लिए लगभग पारदर्शी डाउनलोड;
अतिरिक्त टूल और कॉन्फ़िगरेशन की आवश्यकता है

मॉड्यूल अलगाव

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

मॉड्यूल पृथक नहीं हैं

मॉड्यूल या इसके कुछ हिस्से विश्व स्तर पर उपलब्ध हैं, कहीं से भी कोई भी डेवलपर ले और उपयोग कर सकता है।

 var dep1 = (function () { var a = 10, b = ''; for (var i = 0; i < a; i++) { b += i; } return b; })(); 

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

मॉड्यूल अलग

मॉड्यूल विश्व स्तर पर सुलभ नहीं है, लेकिन इसे नाम जानकर प्राप्त किया जा सकता है - require('pewpew')। छिपाना, जैसा कि मैंने कहा, एक मॉड्यूलर प्रणाली का लक्ष्य नहीं है, लेकिन एक परिणाम है। इस - एएमडी 2 कार्यों जिसके साथ आप किसी भी तरह मॉड्यूल के लिए उपयोग कर सकते हैं नहीं है require()और define()। अपने संसाधनों को प्राप्त करने के लिए मॉड्यूल का कोड नाम जानना पर्याप्त है।

 define('dep3', ['dep1', 'dep2'], function (dep1, dep2) { return function () { return dep1 + dep2; }; }); 

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

मॉड्यूल पूरी तरह से पृथक हैं

ऐसे मॉड्यूल का उद्देश्य बाहर से मॉड्यूल तक पहुंचना असंभव बनाना है। मुझे लगता है कि कई पहले से ही ऐसे "मॉड्यूल" देख चुके हैं, उदाहरण के लिए:

 $(function () { var dep1 = (function () { var a = 10, b = ''; for (var i = 0; i < a; i++) { b += i; } return b; })(); $('button').click(function () { console.log(dep1); }); }); 

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

IEFE में ऐसे मॉड्यूल को लपेटना पर्याप्त है:

 (function () { /* start of deps/dep1.js */ var dep1 = 1; /* start of deps/dep2.js */ var dep2 = 2; var moduleName = function () { return dep1 + dep2; }; })(); 

इस बिल्ड विधि का उपयोग करता है, उदाहरण के लिए, jQuery।

LMD और Browserify भी पर्यावरण से पूरी तरह से अलग मॉड्यूल, लेकिन सभी में एक विधानसभा के विपरीत, उनके मॉड्यूल एक दूसरे से और विधानसभा के "नियंत्रण भाग" से अलग-थलग हैं।

वे इस तरह से घूम रहे हैं:

 (function (main, modules) { function lmd_require() {} // ... main(lmd_require); }) (function (require) { var dep1 = require('dep1'); // ... }, { dep1: function (r,m,e) {} }); 

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

लोकप्रिय जावास्क्रिप्ट मॉड्यूल एमुलेटर की तुलना चार्ट

	AMD, YUI	ES6	सीजेएस / एलएमडी	IEFE
निर्भरता का संकल्प	मॉड्यूल + विन्यास में	मॉड्यूल में	विन्यास में	मैन्युअल रूप से
निर्भरता पहुंच	गतिशील	निवेदक	गतिशील	मनमाना
निर्यात	एक मनमाना नाम के साथ	ईमानदार आयात / निर्यात	एक मनमाना नाम के साथ	अराजक / बेकाबू
साइड मॉड्यूल	स्थैतिक विश्लेषण	जरूरत नहीं / सामंजस्य	असेंबली को कॉन्फ़िगर करें	कड़ी
मॉड्यूल व्याख्या	अनुरोध करने पर	मूल समाधान	अनुरोध करने पर	शुरू में
मॉड्यूल अलगाव	पृथक	पृथक	पूरी तरह से अलग-थलग	अलग-थलग नहीं

सामान्य मॉड्यूल प्रारूप

और अंत में, जावास्क्रिप्ट मॉड्यूलेटर पर कुछ पृष्ठभूमि की जानकारी जो आज मौजूद है।

कोई मॉड्यूल नहीं

 var moduleName = function () { return dep1 + dep2; }; 

नाम स्थान

 var MyNs.moduleName = function () { return MyNs.dep1 + MyNs.dep2; }; 

IIFE वापसी

 var moduleName = (function (dep1, dep2) { return function () { return dep1 + dep2; }; }(dep1, dep2)); 

IIFE निर्यात करता है

 (function (exports, dep1, dep2) { exports.moduleName = function () { return dep1 + dep2; }; }(window, dep1, dep2)); 

एएमडी

YUI मॉड्यूल एएमडी के समान शब्दार्थ हैं। मैं उनका प्रदर्शन नहीं करूंगा।

 define(["dep1", "dep2"], function (dep1, dep2) { return function () { return dep1 + dep2; }; }); 

कॉमन जेजेएस के लिए एएमडी आवरण

 define(function (require, module, exports) { var dep1 = require('dep1'), dep2 = require('dep2'); module.exports = function () { return dep1 + dep2; }; }); 

CommonJS

 var dep1 = require('dep1'), dep2 = require('dep2'); module.exports = function () { return dep1 + dep2; }; 

UMD

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

 (function (root, factory) { if (typeof exports === 'object') { //  1: CommonJS factory(exports, require('dep1'), require('dep2')); } else if (typeof define === 'function' && define.amd) { //  2: AMD ( ) define(['exports', 'dep1', 'dep2'], factory); } else { //  3:    factory(window, root.dep1, root.dep2); } })(this, function (exports, dep1, dep2) { //  exports.moduleName = function () { return dep1 + dep2; }; }); 

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

आदर

1. जावास्क्रिप्ट मॉड्यूल पैटर्न: गहराई में
2. YUI मॉड्यूल बनाना
3. AMD, CommonJS & ES हार्मनी के साथ मॉड्यूलर जावास्क्रिप्ट लिखना
4. एएमडी क्यों?
5. एएमडी जवाब नहीं है
6. एएमडी क्यों नहीं?
7. प्रस्ताव ES6 मॉड्यूल
8. ECMAScript.Harmony मॉड्यूल के साथ ट्रेसुर का उपयोग करके खेलना
9. ईएस 6 में लेखक, एक निर्माण-चरण के रूप में ईएस 5 को ट्रांसपाइल: ग्रंट के लिए एक वर्कफ़्लो

त्रुटियाँ और टाइपोस, कृपया पीएम को भेजें।