👩🏾‍🤝‍👨🏿 ⚾️ 🔰 देशी जावास्क्रिप्ट वस्तुओं का विस्तार - क्या यह बुराई है? सुगरजस प्रकट 🏇🏾 🌙 🤨

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

इसने इस बारे में गर्म चर्चा की कि क्या देशी वस्तुओं को बढ़ाया जा सकता है। मुझे बहुत आश्चर्य हुआ कि लगभग सभी बोलने वाले लोग इसके खिलाफ बोलते थे।

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

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

मैं एंड्रयू प्लमर को मंजिल देता हूं।

तो, चीनी एक पुस्तकालय है जो देशी जावास्क्रिप्ट वस्तुओं को संशोधित करता है। रुको, यह बुराई नहीं है? "आप पूछते हैं," क्या आपने प्रोटोटाइप के कड़वे अनुभव से सबक नहीं सीखा है?

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

पर्यावरण वस्तुओं का संशोधन
प्रगणित गुण के रूप में कार्य
संपत्ति ओवरराइड
वैश्विक नाम स्थान में टकराव
गुणों की कमी के बारे में अनुमान
विनिर्देशों के साथ अनुपालन

1. पर्यावरणीय वस्तुओं का संशोधन

समस्या:

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

विवरण में जाने के बिना, यदि आप पर्यावरण की वस्तुओं को संशोधित करते हैं, तो आपका कोड त्रुटि प्रवण हो सकता है, यह धीमा हो सकता है और पर्यावरण में भविष्य के बदलावों के प्रति संवेदनशील हो सकता है।

चीनी की स्थिति:

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

अनुवादक से: यहाँ नोड रिपॉजिटरी में सुगर मॉड्यूल है।

2. Enumerated Properties के रूप में कार्य

समस्या:

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

विवरण

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

var o = {}; o.name = "Harry"; for(var key in o) { console.log(key); } // => name

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

 Object.prototype.getName = function() { return this.name; }; for(var key in {}) { console.log(key); } // => getName

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

 Object.defineProperty(Object.prototype, 'getName', { value: function() { return this.name; }, enumerable: false }); for(var key in {}) { console.log(key); } // => ()

हालांकि, हमेशा की तरह, एक पकड़ है। इंटरनेट एक्सप्लोरर 8 और उसके नीचे गैर-एन्यूमरबल गुणों को परिभाषित करने की क्षमता उपलब्ध नहीं है।

तो, सामान्य वस्तुओं के गुणों की गणना के साथ, लेकिन सरणियों के बारे में क्या? आमतौर पर, काउंटर के साथ लूप के for एक नियमित रूप से सरणियों के मूल्यों को पार करने के लिए उपयोग किया जाता है।

 Array.prototype.name = 'Harry'; var arr = ['a','b','c']; for(var i = 0; i < arr.length; i++) { console.log(arr[i]); } // => 'a' // => 'b' // => 'c'

जैसा कि आप देख सकते हैं, बस गणना काउंटर से संपत्ति की गणना के साथ समस्याओं से बचा जा सकता है। यदि आप for..in का उपयोग करके ऑब्जेक्ट को बायपास करते हैं, तो for..in प्रॉपर्टीज लूप में आ जाएगी:

 Array.prototype.name = 'Harry'; var arr = ['a','b','c']; for(var key in arr) { console.log(arr[key]); } // => 'a' // => 'b' // => 'c' // => 'Harry'

इस कारण से, hasOwnProperty चक्र में संपत्ति के नाम (और अनुक्रमणिका संख्या द्वारा सरणियों के मानों) द्वारा वस्तुओं के गुणों का उपयोग करते hasOwnProperty , hasOwnProperty विधि का उपयोग किया जाना चाहिए। यह उन गुणों को बाहर करेगा जो सीधे ऑब्जेक्ट से संबंधित नहीं हैं, लेकिन प्रोटोटाइप श्रृंखला के माध्यम से विरासत में मिले हैं:

 Array.prototype.name = 'Harry'; var arr = ['a','b','c']; for(var key in arr) { if(arr.hasOwnProperty(key)) { console.log(arr[key]); } } // => 'a' // => 'b' // => 'c'

यह अच्छी जावास्क्रिप्ट प्रथाओं के सबसे आम उदाहरणों में से एक है। प्रॉपर्टी के नाम से ऑब्जेक्ट प्रॉपर्टी का जिक्र करते समय हमेशा इसका इस्तेमाल करें।

अनुवादक से:

लेखक यह उल्लेख नहीं करता है कि सरणियों का पता Array.prototype.forEach की एक और विधि है: Array.prototype.forEach । त्वरित खोज के परिणामस्वरूप, मुझे मोज़िला डेवलपर नेटवर्क से एक पॉलीफ़िल मिला, जो उनके अनुसार, एल्गोरिदम को विनिर्देशन को पुन: पेश करता है (और, जैसा कि आप निम्नलिखित लिंक से देख सकते हैं, इसमें मूल forEach के समान प्रदर्शन है)। पॉलीफ़िल कोड सरणी को पार करने के लिए पहले (सुरक्षित) तरीके का उपयोग करता है। इसी समय, यह ज्ञात है कि forEach एक काउंटर के साथ लूप के for एक साधारण की तुलना forEach काफी धीमा है , जाहिरा तौर पर अतिरिक्त जांच के कारण।

forEach सभी आधुनिक मोबाइल और डेस्कटॉप ब्राउज़र में उपलब्ध है। IE8 और नीचे में उपलब्ध नहीं है।

चीनी की स्थिति:

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

इस समस्या के कारण (और संपत्तियों को ओवरराइड करने की समस्या के कारण भी) शुगर Object.prototype को संशोधित नहीं करता है, जैसा कि ऊपर के उदाहरणों में किया गया है। इसका मतलब यह है कि रेगुलर जावास्क्रिप्ट ऑब्जेक्ट्स पर for..in लूप्स का उपयोग करने से अज्ञात गुण कभी भी लूप में नहीं आएंगे क्योंकि वे वहां नहीं हैं।

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

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

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

3. ओवरराइडिंग गुण

समस्या:

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

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

 Object.prototype.count = function() {}; var o = { count: 18 }; o.count // => 18

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

चीनी की स्थिति:

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

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

अनुवादक से:

यदि आप चाहें, तो आप साधारण वस्तुओं के साथ एक विशिष्ट वस्तु के गुणों के लिए काम करने के लिए सुगर के तरीकों को स्थानांतरित कर सकते हैं। यह Object.extended() का उपयोग करके किया जाता है:

 var foo = {foo: 'foo'}, bar = {bar: 'bar'}; foo = Object.extended(foo); foo.merge(bar); console.log(foo); // => {foo: 'foo', bar: 'bar'}

4. वैश्विक नाम स्थान में संघर्ष

समस्या:

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

चीनी की स्थिति:

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

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

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

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

अनुवादक से: मेरा मानना है कि किसी भी पुस्तकालय को यथासंभव निर्भरता के लिए प्रयास करना चाहिए, विशेष रूप से ऐसे वैकल्पिक जैसे कि चीनी, अंडरस्कोर और इसी तरह के पुस्तकालय। वे कुछ भी नहीं करते हैं जो शुद्ध जावास्क्रिप्ट में फिर से नहीं लिखा जा सकता है। पुस्तकालयों के लेखकों द्वारा इस नियम का दुरुपयोग इस तथ्य को जन्म दे सकता है कि आपकी परियोजना में डुप्लिकेट और पूरी तरह से अनावश्यक कार्यक्षमता के साथ निर्भरता की गड़बड़ी होगी: Lazy.js, Underscore, Lo-Dash, wu.js, चीनी, Linq.js, JSLINQ, .js, IxJS, Boiler.js, sloth.js, MooTools ... तो सिफारिश "मिडलवेयर में चीनी का उपयोग न करें" अन्य पुस्तकालयों के लिए भी मान्य है।

5. गुणों की कमी के बारे में अनुमान

समस्या:

वैश्विक नाम स्थान में कितने खतरनाक संघर्ष हैं, इसलिए वैश्विक नाम स्थान में निहित (या क्या नहीं) के बारे में धारणाएं हैं।

कल्पना करें कि आपके पास एक फ़ंक्शन है जो दो प्रकार के तर्क ले सकता है: एक स्ट्रिंग और एक वस्तु। यदि किसी ऑब्जेक्ट को फ़ंक्शन में पास किया जाता है, तो उसे उस विशिष्ट संपत्ति से स्ट्रिंग को पुनः प्राप्त करना होगा जो ऑब्जेक्ट के पास है। इसलिए, आप यह देखने के लिए जांचें कि क्या तर्क में यह संपत्ति है:

 function getName(o) { if(o.first) { return firstName; } else { return lastName; } }

यह भ्रामक सरल कोड अंतर्निहित धारणा बनाता है - कि first संपत्ति कभी भी वस्तु की प्रोटोटाइप श्रृंखला में कहीं भी परिभाषित नहीं होगी (भले ही यह एक स्ट्रिंग हो)। बेशक, कोई भी आपको इसकी गारंटी नहीं देगा, क्योंकि Object.prototype और String.prototype वैश्विक ऑब्जेक्ट हैं, और हर कोई उन्हें बदल सकता है।

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

चीनी की स्थिति:

अंतिम उदाहरण से कोड को ठीक करना मुश्किल नहीं है। आप पहले से ही समाधान से परिचित हैं:

 function getName(o) { if(o.hasOwnProperty('first')) { return firstName; } else { return lastName; } }

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

अपने जीवनकाल में, चीनी ने इस समस्या को दो बार बड़े पुस्तकालयों के कोड में उकसाया: jquery # 1140 और mongoose # 482 । दोनों ही मामलों में अपराधी चीनी विधियों के असफल नाम थे। हमने ख़ुशी-ख़ुशी उनका नाम बदला, यही वजह है कि हमने इस समस्या का हल निकाला। इसके अलावा, पुस्तकालयों में से एक (jQuery) ने हमारे साथ समस्या पर काम किया ताकि इसके पक्ष में एक दोष को खत्म किया जा सके।

चीनी वैश्विक दायरे में बहुत सटीक रूप से काम करने की कोशिश करता है, लेकिन पुस्तकालयों के लेखकों के बीच सहयोग के बिना ऐसा करने का कोई तरीका नहीं है। समस्या की जड़ में स्वयं जावास्क्रिप्ट की प्रकृति है, जो गुणों और विधियों के बीच कोई अंतर नहीं करता है।

6. विनिर्देश के साथ अनुपालन

समस्या:

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

चीनी की स्थिति:

शुरुआत से ही, हमने सुगर विकसित किया, जो न केवल विनिर्देश का पालन करने का प्रयास करता है, बल्कि इसके साथ विकसित होने के लिए भी।

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

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

बेशक, अनुकूलन उन उपयोगकर्ताओं के लिए अच्छा है जो नियमित रूप से निर्भरता को अपडेट करने के लिए तैयार हैं। लेकिन चीनी के पुराने संस्करण पर बैठी परियोजनाएं कैसे व्यवहार करेंगी जब पर्यावरण विनिर्देश के अगले संस्करण में बदल जाता है? एक स्थिति की कल्पना करें: आपकी साइट पर आने वाले आगंतुकों के ब्राउज़र अपडेट किए जाते हैं, और उनमें साइट टूट जाती है। चीनी ने हाल ही में उन तरीकों को फिर से परिभाषित करने के लिए एक कठिन निर्णय लिया जो स्पष्ट रूप से विनिर्देश में वर्णित नहीं हैं। अब नहीं if (!Object.prototype.foo) Object.prototype.foo = function(){}; , ECMAScript में अनुपस्थित सभी विधियों को बिना शर्त के पुनः परिभाषित किया जाता है।

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

टीएल / डीआर

आइए सभी समस्याओं और उनसे जुड़े जोखिमों से गुजरें:

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

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

अनुवादक से

प्रदर्शन सुगरजस

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

उन लोगों के लिए जिनके लिए प्रदर्शन महत्वपूर्ण है, मैं LazyJS की सलाह देता हूं । ऐसे मामलों में जहां किसी ऑब्जेक्ट / सरणी के गुणों को ट्रेस करने के बाद, सभी गुणों के साथ एक नई ऑब्जेक्ट को वापस करना आवश्यक नहीं है, LazyJS प्रदर्शन में लो-डैश से बेहतर प्रदर्शन करता है। यौगिक क्रियाओं में, अंतराल महत्वपूर्ण हो जाता है। उदाहरण के लिए, map -> filter ऑपरेशन, लेजीजेएस लो-डैश की तुलना में पांच गुना तेज है, और सुगरजेस की तुलना में पंद्रह है। यदि आपको न केवल संपत्ति मूल्यों के माध्यम से जाने की जरूरत है, बल्कि एक नई वस्तु / सरणी को इकट्ठा करना है, तो LazyJS अपना लाभ खो देता है। StreetStrider बताता है कि LoDash संस्करण 3 में आलसी चेन कंप्यूटिंग की योजना है।

यहां (अंग्रेजी), आप सीधे अपने ब्राउज़र में विभिन्न प्रकार के विशिष्ट कार्यों पर दस समान पुस्तकालयों के प्रदर्शन की तुलना कर सकते हैं।

हमने जो सुविधा खो दी है

आप सोच रहे होंगे कि रूबी में देशी वस्तुओं के विस्तार की समस्या का कितना हल किया गया। इसने शोधन तंत्र प्रस्तावित किया, जो कि रूबी 2.1 में प्रायोगिक स्थिति से बाहर आया।

मान लीजिए कि डेवलपर वास्या, जो वास्या पुस्तकालय लिखता है, तो डिकॉय पैच बनाने के बारे में शर्मीली नहीं है: वह (फिर से) अपने पुस्तकालय से मानक वस्तुओं के तरीकों को परिभाषित करता है जो refine निर्माण का उपयोग करते हैं।

 refine String do def petrovich "Petrovich says: " + self end end

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

नए तरीकों का उपयोग करने के लिए, पेटीया अपने कोड में इंगित करता है कि कौन सी लाइब्रेरी से कौन से डिकॉय पैच चाहिए:

 using Vasya using HollowbodySixString1957

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

UPD1: यह सब क्यों आवश्यक है?

टिप्पणियों से यह स्पष्ट हो गया कि यह मेरे लिए स्पष्ट है। मैं टिप्पणियों से अपना जवाब देता हूं।

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

जब आप इस कोड को देखते हैं (सार उदाहरण):

 var result = Math.floor( MyArray.last( arr ) ); if (debug) console.log( "result:", result ); return result;

... इसके बजाय:

 return arr.last().floor().debug();

... तो यह किसी तरह हो जाता है, तुम्हें पता है, सुनसान।

देशी जावास्क्रिप्ट वस्तुओं का विस्तार - क्या यह बुराई है? सुगरजस प्रकट

1. पर्यावरणीय वस्तुओं का संशोधन

समस्या:

चीनी की स्थिति:

2. Enumerated Properties के रूप में कार्य

समस्या:

चीनी की स्थिति:

3. ओवरराइडिंग गुण

समस्या:

चीनी की स्थिति:

4. वैश्विक नाम स्थान में संघर्ष

समस्या:

चीनी की स्थिति:

5. गुणों की कमी के बारे में अनुमान

समस्या:

चीनी की स्थिति:

6. विनिर्देश के साथ अनुपालन

समस्या:

चीनी की स्थिति:

टीएल / डीआर

अनुवादक से

प्रदर्शन सुगरजस

हमने जो सुविधा खो दी है

UPD1: यह सब क्यों आवश्यक है?

More articles: