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

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

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

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

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

सामग्री

• उपयोग की शर्तें
• मुद्दों पर अधिक
• सीधे परिभाषित निर्भरताएँ (1999)
• नेमस्पेस पैटर्न (2002)
• मॉड्यूल पैटर्न (2003)
• खाका परिभाषित निर्भरताएँ (2006)
• टिप्पणी परिभाषित निर्भरताएँ (2006)
• बाह्य रूप से परिभाषित निर्भरताएँ (2007)
• सैंडबॉक्स पैटर्न (2009)
• निर्भरता इंजेक्शन (2009)
• कॉमनजेएस मॉड्यूल (2009)
• AMD (2009)
• UMD (2011)
• लेबल किए गए मॉड्यूल (2012)
• YModules (2013)
• ES2015 मॉड्यूल (2015)
• कुल मिलाकर

उपयोग की शर्तें

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

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

"अलग की गई निर्भरता परिभाषा (डीडीडी)" से हमारा मतलब है कि ऐसे निर्भरता निर्धारण दृष्टिकोण जो कि मॉड्यूलर सिस्टम के स्वतंत्र रूप से उपयोग किए जा सकते हैं।

मुद्दों पर अधिक

न्यूनाधिकता की दुनिया में गोता लगाने से पहले, आइए देखें कि हम किन समस्याओं का सामना करते हैं।

नाम की टक्कर

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

 //  greeting.js var helloInLang = { en: 'Hello world!', es: '¡Hola mundo!', ru: ', !' }; function writeHello(lang) { document.write(helloInLang[lang]); } //  hello.js function writeHello() { document.write('The script is broken'); } 

जब greeting.js hello.js और फिर hello.js पृष्ठ से जुड़े hello.js , तो हम टकराव के कारण ग्रीटिंग के बजाय "स्क्रिप्ट टूट गया है" संदेश प्राप्त करेंगे।

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

बड़े कोडबेस सपोर्ट

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

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

सीधे परिभाषित निर्भरताएँ (1999)

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

तब एरिक ने एक स्टार्टअप में काम किया, जहां उसने एक ब्राउज़र में GUI एप्लिकेशन लॉन्च करने के लिए एक मंच बनाया - वेबओएस (नोट: यह पाम से वेबओएस के बारे में नहीं है)। वेबओएस एक मालिकाना मंच था - मुझे इसका स्रोत कोड नहीं मिला। इसलिए, हम डोजो लाइब्रेरी के उदाहरण पर पैटर्न के कार्यान्वयन पर विचार करेंगे, जिसे 2004 से एलेक्स रसेल और डायलन स्किमैन द्वारा विकसित किया गया है।

निर्भरता की प्रत्यक्ष परिभाषा का सार dojo.require फ़ंक्शन (जो, इसके अलावा, लोड किए गए मॉड्यूल को इनिशियलाइज़ किया है) के स्पष्ट निष्पादन के साथ मॉड्यूल के कोड (Dojo - संसाधनों के संदर्भ में) को लोड करना है। इस दृष्टिकोण के साथ, निर्भरताएं आवश्यकता के स्थान से निर्धारित होती हैं, सीधे कोड में।

आइए Dojo 1.6 का उपयोग करके हमारे उदाहरण को फिर से बनाएं:

 //  greeting.js dojo.provide("app.greeting"); app.greeting.helloInLang = { en: 'Hello world!', es: '¡Hola mundo!', ru: ', !' }; app.greeting.sayHello = function (lang) { return app.greeting.helloInLang[lang]; }; //  hello.js dojo.provide("app.hello"); dojo.require('app.greeting'); app.hello = function(x) { document.write(app.greeting.sayHello('es')); }; 

यहाँ हम देखते हैं कि मॉड्यूल dojo.provide फ़ंक्शन का उपयोग करके परिभाषित किया गया है, और dojo.require फ़ंक्शन dojo.require होने पर कोड लोड किया dojo.require । यह एक काफी सरल दृष्टिकोण है जो कि संस्करण 1.7 से पहले Dojo में उपयोग किया गया था और अभी भी Google बंद लाइब्रेरी में उपयोग किया जाता है।

नेमस्पेस पैटर्न (2002)

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

प्रथम श्रेणी का एक ऑब्जेक्ट एक इकाई है जिसे वस्तुओं के चर और गुणों को सौंपा जा सकता है और अन्य कार्यों से लौटाया जा सकता है। अर्थात्, आप दस्तावेज़ और विंडो ऑब्जेक्ट ( document.write() , window.alert() ) के रूप में समान फ़ंक्शन गुणों (विधियों) के साथ ऑब्जेक्ट बना सकते हैं।

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

आइए इस विचार को अपने उदाहरण में रखें।

 //  app.js var app = {}; //  greeting.js app.helloInLang = { en: 'Hello world!', es: '¡Hola mundo!', ru: ', !' }; //  hello.js app.writeHello = function (lang) { document.write(app.helloInLang[lang]); 

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

आज, नामस्पेस पैटर्न संभवतः सबसे लोकप्रिय पैटर्न है जो जेएस में पाया जा सकता है। विंडोज के बाद, इसी तरह का तर्क Dojo (2005), YUI (2005), और कई अन्य पुस्तकालयों और रूपरेखाओं में दिखाई दिया। यह ध्यान देने योग्य है कि एरिक खुद को इस दृष्टिकोण का लेखक नहीं मानता है , लेकिन, दुर्भाग्य से, वह याद नहीं कर सका कि किस परियोजना ने उसे पैटर्न का उपयोग करने के लिए प्रेरित किया।

मॉड्यूल पैटर्न (2003)

नेमस्पेस के लिए धन्यवाद, कोड का संगठन थोड़ा कम गड़बड़ हो गया, लेकिन यह स्पष्ट था कि यह पर्याप्त नहीं था: कोड और डेटा को अलग करने की समस्या अभी तक हल नहीं हुई है।

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

 var greeting = (function () { var module = {}; var helloInLang = { en: 'Hello world!', es: '¡Hola mundo!', ru: ', !' }; module.getHello = function (lang) { return helloInLang[lang]; }; module.writeHello = function (lang) { document.write(module.getHello(lang)) }; return module; }()); 

यहां हम एक स्व-चालान समारोह देखते हैं - एक जो घोषणा के तुरंत बाद निष्पादित होता है। यह एक module ऑब्जेक्ट लौटाता है, जहां एक getHello() विधि है जो एक क्लोजर के माध्यम से helloInLang ऑब्जेक्ट तक helloInLang । इस प्रकार, helloInLang बाहरी दुनिया से अप्राप्य हो जाता है और हमें एक परमाणु कोड मिलता है जिसे किसी अन्य स्क्रिप्ट में बिना नाम संघर्ष के डाला जा सकता है - भले ही helloInLang ऑब्जेक्ट कहीं और घोषित किया गया हो।

नेट पर इस दृष्टिकोण का पहला उल्लेख 2003 में सामने आया था, जब रिचर्ड कोर्नफोर्ड ने comp.lang.javascript समूह में एक मॉड्यूल का उदाहरण दिया था जिसमें क्लोजर के उपयोग का वर्णन किया गया था। 2005-2006 में, याहू के YUI ढांचे के डेवलपर्स द्वारा इस दृष्टिकोण को अपनाया गया था! डगलस क्रॉकफोर्ड के नेतृत्व में। लेकिन इसके वितरण के लिए सबसे बड़ी प्रेरणा 2008 में दी गई थी, जब डगलस ने अपनी जावास्क्रिप्ट पुस्तक गुड पार्ट्स में "मॉड्यूल" पैटर्न का वर्णन किया था।

लेकिन यह सब नहीं है। "जावास्क्रिप्ट मॉड्यूल पैटर्न: इन-डेप्थ" (यहां हब्राब्र में अनुवाद है ) लेख में मॉड्यूल को लागू करने के लिए कई अलग-अलग विकल्प हैं। मैं देखने की सलाह देता हूं।

खाका परिभाषित निर्भरताएँ (2006)

निर्भरता की टेम्पलेट परिभाषा स्टैंड-अलोन परिभाषा परिवार में अगला पैटर्न है। सबसे पहली परियोजना मैंने यह पाया है कि इस दृष्टिकोण का उपयोग प्रोटोटाइप 1.4 (2006) है, लेकिन मुझे संदेह है कि इसका उपयोग पुस्तकालय के पुराने संस्करणों में किया गया था।

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

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

एक अलग परिभाषा के पहले से चर्चा किए गए पैटर्न के विपरीत - अस्थायी निर्भरता का उपयोग करते समय - प्रारंभिक विधानसभा चरण की आवश्यकता होती है।

चलो वर्णित शैली का उपयोग करके हमारे उदाहरण को बदलते हैं। ऐसा करने के लिए, बोरशिक का उपयोग करें:

 //  app.tmp.js /*borschik:include:../lib/main.js*/ /*borschik:include:../lib/helloInLang.js*/ /*borschik:include:../lib/writeHello.js*/ //  main.js var app = {}; //  helloInLang.js app.helloInLang = { en: 'Hello world!', es: '¡Hola mundo!', ru: ', !' }; //  writeHello.js app.writeHello = function (lang) { document.write(app.helloInLang[lang]); }; 

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

टिप्पणी परिभाषित निर्भरताएँ (2006)

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

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

यदि हम LazyJS का उपयोग करके इसे फिर से लिखते हैं तो हमारा उदाहरण क्या दिखेगा:

 //  helloInLang.js var helloInLang = { en: 'Hello world!', es: '¡Hola mundo!', ru: ', !' }; //  sayHello.js /*! lazy require scripts/app/helloInLang.js */ function sayHello(lang) { return helloInLang[lang]; } //  hello.js /*! lazy require scripts/app/sayHello.js */ document.write(sayHello('en')); 

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

बाह्य रूप से परिभाषित निर्भरताएँ (2007)

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

इस दृष्टिकोण का जल्द से जल्द उपयोग कि मुझे 2007 की तारीखें मिलें। यह MooTools 1.1 पुस्तकालय के बारे में है।

सरलतम स्थिति में, हम इस पैटर्न का उपयोग करके अपने उदाहरण को लागू कर सकते हैं (मैं बूटलोडर के अपने स्वयं के प्रयोगात्मक कार्यान्वयन का उपयोग एक उदाहरण के रूप में करूंगा, जहां वांछित पैटर्न शामिल है):

 //  deps.json { "files": { "main.js": ["sayHello.js"], "sayHello.js": ["helloInLang.js"], "helloInLang.js": [] } } //  helloInLang.js var helloInLang = { en: 'Hello world!', es: '¡Hola mundo!', ru: ', !' }; //  sayHello.js function sayHello(lang) { return helloInLang[lang]; } //  main.js console.log(sayHello('en')); 

deps.json फ़ाइल बहुत ही बाहरी संदर्भ है जहां सभी निर्भरताएं परिभाषित की गई हैं। जब आवेदन शुरू होता है, तो लोडर फ़ाइल प्राप्त करता है, उसमें से निर्भरताएं पढ़ता है, जिन्हें एक सरणी के रूप में परिभाषित किया गया है, उन्हें लोड करता है और सही क्रम में पृष्ठ से जोड़ता है।

फिलहाल, इस दृष्टिकोण का उपयोग कुछ पुस्तकालयों में कस्टम असेंबली बनाने के लिए किया जाता है, उदाहरण के लिए, लॉश में ।

सैंडबॉक्स पैटर्न (2009)

नए YUI3 मॉड्यूलर सिस्टम पर काम करने वाले याहू! प्रोग्रामर्स ने एक पेज पर लाइब्रेरी के विभिन्न संस्करणों का उपयोग करने की समस्या को हल किया। YUI3 से पहले, ढांचे में एक मॉड्यूलर प्रणाली को मॉड्यूल और नेमस्पेस पैटर्न के संयोजन से लागू किया गया था। जाहिर है, ऐसी योजना के साथ, लाइब्रेरी कोड वाली रूट ऑब्जेक्ट केवल एक ही हो सकती है, और इसलिए एक साथ कई संस्करणों का उपयोग करना मुश्किल था।

समस्या को हल करने के लिए, YUI3 डेवलपर्स में से एक एडम मूर ने सैंडबॉक्स का उपयोग करने का सुझाव दिया। इस पैटर्न का उपयोग करते हुए एक साधारण मॉड्यूलर कार्यान्वयन इस तरह लग सकता है:

 //  sandbox.js function Sandbox(callback) { var modules = []; for (var i in Sandbox.modules) { modules.push(i); } for (var i = 0; i < modules.length; i++) { this[modules[i]] = Sandbox.modules[modules[i]](); } callback(this); } //  greeting.js Sandbox.modules = Sandbox.modules || {}; Sandbox.modules.greeting = function () { var helloInLang = { en: 'Hello world!', es: '¡Hola mundo!', ru: ', !' }; return { sayHello: function (lang) { return helloInLang[lang]; } }; }; //  app.js new Sandbox(function(box) { document.write(box.greeting.sayHello('es')); }); 

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

सैंडबॉक्स ने मॉड्यूलरिटी समस्या का एक दिलचस्प समाधान के रूप में कार्य किया, लेकिन YUI3 के बाहर व्यापक रूप से नहीं फैला था। यदि आप सैंडबॉक्स के बारे में अधिक जानना चाहते हैं, तो मैं "जावास्क्रिप्ट सैंडबॉक्स पैटर्न" लेख, साथ ही नए पुस्तकालय मॉड्यूल बनाने के बारे में आधिकारिक YUI प्रलेखन की सलाह देता हूं।

निर्भरता इंजेक्शन (2009)

2004 में, मार्टिन फाउलर ने जावा में एक नए घटक संचार तंत्र का वर्णन करने के लिए निर्भरता इंजेक्शन (DI) की अवधारणा पेश की। मुख्य बिंदु यह है कि सभी निर्भरताएं घटक के बाहर से आती हैं। दूसरे शब्दों में, घटक अपनी निर्भरता को शुरू करने के लिए जिम्मेदार नहीं है, लेकिन केवल उनका उपयोग करता है।

पांच साल बाद, सन और एडोब (जहां वह जावा के विकास में शामिल थे) के एक पूर्व कर्मचारी मिश्को हेवरी ने अपने स्टार्टअप के लिए एक जावास्क्रिप्ट ढांचा तैयार करना शुरू किया, जहां निर्भरता इंजेक्शन घटक संबंधों का प्रमुख तंत्र था। व्यवसाय के विचार ने इसकी प्रभावशीलता को साबित नहीं किया, लेकिन उन्होंने स्टार्टअप डोमेन getangular.com पर फ्रेमवर्क के स्रोत कोड को डालने का फैसला किया। अधिकांश लोग जानते हैं कि बाद में क्या हुआ: Google ने मिशको और उनके प्रोजेक्ट को विंग के तहत लिया और अब एंगुलर सबसे प्रसिद्ध जावास्क्रिप्ट फ्रेमवर्क में से एक है।

कोणीय में मॉड्यूल DI तंत्र का उपयोग करके कार्यान्वित किए जाते हैं। हालाँकि, प्रतिरूपकता DI का प्राथमिक उद्देश्य नहीं है: मिश्को भी इसी प्रश्न के उत्तर में स्पष्ट रूप से इस बारे में बात करता है।

दृष्टिकोण का वर्णन करने के लिए, आइए, कोणीय के पहले संस्करण का उपयोग करके अपने उदाहरण को फिर से लिखें, (उदाहरण के लिए, यह बेहद संश्लिष्ट निकला):

 //  greeting.js angular.module('greeter', []) .value('greeting', { helloInLang: { en: 'Hello world!', es: '¡Hola mundo!', ru: ', !' }, sayHello: function(lang) { return this.helloInLang[lang]; } }); //  app.js angular.module('app', ['greeter']) .controller('GreetingController', ['$scope', 'greeting', function($scope, greeting) { $scope.phrase = greeting.sayHello('en'); }]); 

यदि आप ब्राउज़र में उदाहरण पृष्ठ खोलते हैं, तो कोड जादुई रूप से काम करेगा और हम पृष्ठ पर परिणाम देखेंगे।

अब DI तंत्र का उपयोग कोणीय 2 और स्लॉट ढांचे में किया जाता है। बड़ी संख्या में पुस्तकालय भी हैं जो अनुप्रयोगों में इस दृष्टिकोण के उपयोग को सरल बनाते हैं जो किसी भी ढांचे पर निर्भर नहीं हैं।

कॉमनजेएस मॉड्यूल (2009)

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

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

काम में उबाल आने लगा। जावास्क्रिप्ट में मॉड्यूल प्रारूप के विनिर्देश पर सबसे अधिक ध्यान दिया गया था - कॉमनजेएस मॉड्यूल (कभी-कभी सीजेएस या सिर्फ कॉमनजेएस) कहा जाता है, जिसे अंततः नोड.जेएस में लागू किया गया था।

CommonJS मॉड्यूल को प्रदर्शित करने के लिए, आइए अपने मॉड्यूल को इस प्रकार से अनुकूलित करें

 //  greeting.js var helloInLang = { en: 'Hello world!', es: '¡Hola mundo!', ru: ', !' }; var sayHello = function (lang) { return helloInLang[lang]; } module.exports.sayHello = sayHello; //  hello.js var sayHello = require('./lib/greeting').sayHello; var phrase = sayHello('en'); console.log(phrase); 

यहां हम देखते हैं कि प्रतिरूपकता के कार्यान्वयन के लिए, नई संस्थाओं की require और exports ( module.exports पर अन्य नाम) पेश किए जाते हैं, जो एक मॉड्यूल को लोड करना और बाहरी दुनिया को अपना इंटरफ़ेस प्रदान करना संभव बनाते हैं। यह ध्यान देने योग्य है कि न तो require , न ही exports , और न ही मॉड्यूल भाषा के कीवर्ड हैं - वे Node.js में दिखाई देते हैं आवरण के लिए धन्यवाद जहां जावास्क्रिप्ट इंजन भेजे जाने से पहले सभी मॉड्यूल लपेटे जाते हैं:

 (function (exports, require, module, __filename, __dirname) { // ... // Your code is injected here! // ... }); 

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

बाबेल की require तब require जब ES2015 मॉड्यूल प्रारूप में डिफ़ॉल्ट निर्यात के साथ एक मॉड्यूल ट्रांसप्लानिंग (हम लेख के अंत में इस मॉड्यूलर प्रणाली के बारे में बात करेंगे):

 export default something; 

बैबेल इस तरह के निर्यात को कॉमनजस मॉड्यूल में परिवर्तित करता है, जहां डिफ़ॉल्ट मूल्य को संबंधित संपत्ति का उपयोग करके निर्यात किया जाता है। यह सरल है, निम्नलिखित कोड प्राप्त किया जाता है:

 exports.default = something; 

वेबपैक निर्माण प्रणाली भी विभिन्न एक्सटेंशन का उपयोग करती है, उदाहरण के लिए। require.ensure , require.cache , require.context , लेकिन उनकी चर्चा लेख के संदर्भ से बाहर है।

आज, कॉमनजस सबसे आम मॉड्यूल प्रारूप है। इस प्रारूप का उपयोग न केवल Node.JS में किया जाता है - इसका उपयोग क्लाइंट वेब एप्लिकेशन विकसित करते समय, ब्राउज़र मॉड्यूल या वेबपैक का उपयोग करके सभी मॉड्यूल को एक फ़ाइल में एकत्रित करने में भी किया जा सकता है।

AMD (2009)

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

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

, , — ( , ); . , AMD (Asynchronous Module Definition).

AMD, :

 // file lib/greeting.js define(function() { var helloInLang = { en: 'Hello world!', es: '¡Hola mundo!', ru: ', !' }; return { sayHello: function (lang) { return helloInLang[lang]; } }; }); // file hello.js define(['./lib/greeting'], function(greeting) { var phrase = greeting.sayHello('en'); document.write(phrase); }); 

hello.js . define , . . , define , , . .

2011 : AMD, CommonJS .

, AMD , npm bower AMD .

UMD (2011)

, AMD CommonJS Modules. AMD , . CommonJS Modules - Node.js Browserify .

, . AMD- , CommonJS Modules (Node.js), CommonJS , AMD: RequireJS, curl.js. , RequireJS CommonJS-, . UMD — Universal Module Definition .

— . UMD GitHub . , , , Q .

Q : ( script) Node.js Narwhal ( CommonJS Modules). , Q AMD. , UMD. UMD.

CommonJS AMD:

 (function(define) { define(function () { var helloInLang = { en: 'Hello world!', es: '¡Hola mundo!', ru: ', !' }; return { sayHello: function (lang) { return helloInLang[lang]; } }; }); }( typeof module === 'object' && module.exports && typeof define !== 'function' ? function (factory) { module.exports = factory(); } : define )); 

, . :

 function (factory) { module.exports = factory(); } 

CommonJS-. AMD-, define. .

, , Node.js, UMD. UMD , moment.js lodash .

Labeled Modules (2012)

2010 39 JavaScript. ES6 Modules. 2012 , . , ( React), . , , ES3, , , . Labeled Modules .

— (labels). import export , : — exports, — require.

, , .

 //  greeting.js var helloInLang = { en: 'Hello world!', es: '¡Hola mundo!', ru: ', !' }; exports: var greeting = { sayHello: function (lang) { return helloInLang[lang]; } }; //  hello.js require: './lib/greeting'; var phrase = greeting.sayHello('es'); document.write(phrase); 

, Labeled Modules, .

, . 2012 CommonJS AMD, . , Labeled Modules webpack , JS- .

YModules (2013)

;). - , CommonJS AMD? , , CommonJS, AMD .

. API ( API .) , JS- . , , — .

2013 , dfilatov .

YModules :

 //  greeting.js modules.define('greeting', function(provide) { provide({ helloInLang: { en: 'Hello world!', es: '¡Hola mundo!', ru: ', !' }, sayHello: function (lang) { return this.helloInLang[lang]; } }); }); //  app.js modules.require(['greeting'], function(greeting) { document.write(greeting.sayHello('ru')); }); // : ", !" 

YModules AMD. — provide , return .

«» , . , greeting.js - ( — setTimeout ), , , :

 //  greeting.js modules.define('greeting', function(provide) { //     1  setTimeout(function () { provide({ helloInLang: { en: 'Hello world!', es: '¡Hola mundo!', ru: ', !' }, sayHello: function (lang) { return this.helloInLang[lang]; } }); }, 1000); }); // : app.js modules.require(['greeting'], function(greeting) { document.write(greeting.sayHello('ru')); }); // : ", !" 

, YModules . .

 //  moduleOnLevel1.js modules.define('greeting', function(provide) { provide({ helloInLang: { en: 'Hello world!', es: '¡Hola mundo!', ru: ', !' }, sayHello: function (lang) { return this.helloInLang[lang]; } }); }); //  moduleOnLevel2.js modules.define('greeting', function(provide, module) { //   sayHello module.sayHello = function (lang) { return module.helloInLang[lang].toUpperCase(); }; provide(module); }); //  app.js modules.require(['greeting'], function(greeting) { document.write(greeting.sayHello('ru')); }); // : ", !" 

, sayHello greeting , . , YModules (, module ).

YModules . i-bem.js .

ES2015 Modules (2015)

ECMAScript (TC39), , , JavaScript. , .

2010 Mozilla . , . asm.js, emscripten, servo.

, 2015 ES2015, , , . :

 //  lib/greeting.js const helloInLang = { en: 'Hello world!', es: '¡Hola mundo!', ru: ', !' }; export const greeting = { sayHello: function (lang) { return helloInLang[lang]; } }; //  hello.js import { greeting } from "./lib/greeting"; const phrase = greeting.sayHello("ru"); document.write(phrase); 

, import export .

- , , , Module Loader API, , , .

, ES2015 . , ES5, Babel : .

कुल मिलाकर

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

« JavaScript » , , .

GitHub .