क्या आईआईएफई का उपयोग कर मॉड्यूल.एक्सपोर्ट को परिभाषित करने का कोई कारण है?

Question

मेरी टीम के पास कोई अनुभवी जेएस डेवलपर नहीं है, लेकिन हम नोड में एक लाइब्रेरी लिख रहे हैं और एक वास्तविक जेएस डेवलपर से एक सुझाव मिला है कि "हमें जेएस को अधिक मॉड्यूलर बनाना चाहिए - वैश्विक नामस्थान को प्रदूषित नहीं करना और इसे बनाना नए आने वालों के लिए "अधिक पठनीय है, और हमें बताया करने के लिए निम्नलिखित:

module.exports = (function(){ 
     return { 
     nameToExpose: functionToExpose 
     ... 
    }; 
})(); 

बल्कि

module.exports.nameToExpose = functionToExpose; 

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

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

Answer 1

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

जब आप फ्रंट एंड स्टफ से निपट रहे हैं, तब जब वैश्विक क्षेत्र चिंता का विषय बन जाता है, क्योंकि यदि कोई फ़ंक्शन या जो भी स्कॉप्ड नहीं होता है (यानी, आईआईएफई या अन्य फ़ंक्शन ब्लॉक में), तो वैश्विक window ऑब्जेक्ट तक पहुंच है, और बाकी सब कुछ उस फ़ंक्शन तक पहुंच है।

कोई वास्तविक जे एस डेवलपर

कॉलिंग किसी एक लाल झंडा है।

वैश्विक नामस्थान को दूषित करने के लिए नहीं है और यह अधिक नए आने वालों

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

module.exports = function() { ... } // whatever 

और भले ही यह किया था, वे मॉड्यूल फाइल करने के लिए स्थानीय और पूरे कार्यक्रम कि require() यह है करने के लिए वैश्विक नहीं होगा।

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

Answer 2

करने का कारण हो सकता है कभी कभी ऐसा करने है क्योंकि अगर आप ऐसा नहीं करते, तो कोई भी चर आप module.exports वस्तु के लिए की जरूरत पूरी फ़ाइल के दायरे वाला होना चाहिए।

इन दो तरीकों पर विचार करें।

1. आईआईएफई के बिना।

   var foo = 'la' + 'la'; // some computed value 
   
   // 
   // ... lots of program code here ... 
   // 
   
   module.exports = { 
       foo : foo, 
   }; 
   

2. आईआईएफई के साथ।

   // 
   // ... lots of program code here ... 
   // 
   
   module.exports = (function() { 
       var foo = 'la' + 'la'; // some computed value 
       return { 
        foo : foo 
       } 
   }()); 
   

पहले उदाहरण में, दो में समस्या आने पर।

1. आपके चर (जैसे foo) मॉड्यूल से मूल्य निर्यात करने के लिए उपयोग किए जाने से बहुत दूर बनाए जाते हैं। यह स्पष्टता को कम कर सकता है। निश्चित रूप से, आप प्रोग्राम कोड के बाद एक चर घोषित कर सकते हैं, लेकिन यह अभी भी वही दायरा है (और var एस hoisted हैं)। इसके अलावा, सामान्य सर्वोत्तम अभ्यास अपने सभी चरों को सामने घोषित करना है, और ऐसा नहीं करना एक व्यापारिक विचार है।
2. प्रोग्राम कोड आपके चर, जानबूझकर या आकस्मिक रूप से गड़बड़ कर सकता है, जो चीजों को जटिल करता है और जब तक आपको इसकी आवश्यकता नहीं होती है तब तक अवांछनीय है (कभी-कभी आप करते हैं)।

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

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

अद्यतन:

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

// 
// ... lots of program code here ... 
// 

const foo = 'la' + 'la'; // some computed value 

module.exports = { 
    foo : foo, 
}; 

उपरोक्त उदाहरण में, यदि प्रोग्राम कोड foo का उपयोग करता है, यह एक ReferenceError साथ Temporal Dead Zone की वजह से, के रूप में होगा एक var रूप undefined प्राप्त करने के लिए विरोध दुर्घटना जाएगा। यह बहुत अच्छा है क्योंकि अब यदि कोड का उपयोग जानबूझकर था, या अन्यथा कोड को ठीक किया गया है तो आपको कोड में पहले की जगह foo की घोषणा को स्पष्ट रूप से स्थानांतरित करना होगा।