🎋 👨🏼‍✈️ 🤰🏿 DOM के साथ काम करने के लिए एक बेहतर JavaScript लाइब्रेरी बनाने के बारे में 🍈 👊🏾 👩🏼‍🎓

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

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

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

पुस्तकालय में उपयोगी सुविधाओं को जोड़ना

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

लाइव एक्सटेंशन
देशी एनिमेशन
बिल्ट-इन टेम्पलेट इंजन
अंतर्राष्ट्रीयकरण समर्थन

लाइव एक्सटेंशन

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

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

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

 DOM.extend("[title]", { constructor: function() { var tooltip = DOM.create("span.custom-title"); //  textContent     // title       tooltip.set("textContent", this.get("title")).hide(); this //   tooltip .set("title", null) //       .data("tooltip", tooltip) //    .on("mouseenter", this.onMouseEnter, ["clientX", "clientY"]) .on("mouseleave", this.onMouseLeave) //     DOM .append(tooltip); }, onMouseEnter: function(x, y) { this.data("tooltip").style({left: x, top: y}).show(); }, onMouseLeave: function() { this.data("tooltip").hide(); } });

हमारे टूलटिप को अब CSS में .custom-title चयनकर्ता का उपयोग करके स्टाइल किया जा सकता है:

 .custom-title { position: fixed; border: 1px solid #faebcc; background: #faf8f0; }

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

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

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

वेब घटक के अन्य वर्गों के विपरीत, सज्जाकार के पास अभी तक विनिर्देश नहीं हैं।

देशी एनिमेशन

Apple के लिए धन्यवाद , CSS में अब अच्छा एनीमेशन सपोर्ट है । अतीत में, एनिमेशन में setInterval और setTimeout का उपयोग करके जावास्क्रिप्ट को लागू किया गया था। यह एक अच्छी बात थी, लेकिन अब ... थोड़ा बुरा अभ्यास। मूल एनिमेशन हमेशा स्मूद रहेंगे: वे आमतौर पर तेज़ होते हैं, कम बिजली की आवश्यकता होती है, और केवल उन ब्राउज़रों में दिखाई नहीं देते जो उनका समर्थन नहीं करते हैं।

बेहतर-डोम में कोई animate विधि नहीं है: केवल show , hide और toggle । CSS में छिपे हुए तत्व की स्थिति को पकड़ने के लिए, पुस्तकालय मानकीकृत aria-hidden विशेषता का उपयोग करता है।

दृष्टिकोण को स्पष्ट करने के लिए, आइए एक सरल टूलटिप एनीमेशन जोड़ें जो हमने पहले लिखा था:

 .custom-title { position: fixed; border: 1px solid #faebcc; background: #faf8f0; /*  */ opacity: 1; -webkit-transition: opacity 0.5s; transition: opacity 0.5s; } .custom-title[aria-hidden=true] { opacity: 0; }

show अंदर और hide aria-hidden विशेषता इसके मूल्य को false या true । यह CSS का उपयोग करके एनिमेशन दिखाने के लिए पर्याप्त है।

बेहतर-डोम के साथ अधिक एनीमेशन उदाहरण।

बिल्ट-इन टेम्पलेट इंजन

HTML स्ट्रिंग्स भारी हैं। जब मैंने प्रतिस्थापन की तलाश शुरू की, तो मुझे एक बेहतरीन एम्मेट प्रोजेक्ट मिला। वर्तमान में, यह पाठ संपादकों के लिए एक प्लगइन के रूप में काफी लोकप्रिय है और इसमें स्वच्छ और कॉम्पैक्ट सिंटैक्स है। की तुलना करें:

 body.append("<ul><li class='list-item'></li><li class='list-item'></li><li class='list-item'></li></ul>");

जो समकक्ष है

 body.append("ul>li.list-item*3");

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

अंतर्राष्ट्रीयकरण का समर्थन

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

एक वैचारिक दृष्टिकोण से, किसी भाषा को बदलना सामग्री की "प्रस्तुति" को बदलने जैसा है। CSS2 में कई छद्म चयनकर्ता हैं जो ऐसे मॉडल का वर्णन करने में मदद करते हैं :lang और :before । नीचे दिए गए कोड पर एक नज़र डालें:

 [data-i18n="hello"]:before { content: "Hello Maksim!"; } [data-i18n="hello"]:lang(ru):before { content: " !"; }

चाल यह है कि content संपत्ति वर्तमान भाषा के अनुसार बदलती है, जो html तत्व के लिए lang विशेषता के मूल्य से निर्धारित होती है। data-i18n विशेषता का उपयोग करते हुए, हम अधिक सामान्य अंकन का उपयोग कर सकते हैं:

 [data-i18n]:before { content: attr(data-i18n); } [data-i18n="Hello Maksim!"]:lang(ru):before { content: " !"; }

बेशक, इस तरह के CSS कोड आकर्षक नहीं लगते हैं, इसलिए बेहतर-डोम में दो DOM.importStrings हैं: i18n और DOM.importStrings । पहले का उपयोग संबंधित मान के साथ data-i18n विशेषता को अपडेट करने के लिए किया जाता है, और दूसरा विशिष्ट भाषा के लिए स्ट्रिंग्स को स्थानीय करता है।

 label.i18n("Hello Maksim!"); // label  "Hello Maksim!" DOM.importStrings("ru", "Hello Maksim!", " !"); //     "ru",  label   " !" label.set("lang", "ru"); //  label  " !"

पैरामीटर किए गए तार भी समर्थित हैं: बस कुंजी स्ट्रिंग में ${param} चर जोड़ें:

 label.i18n("Hello ${user}!", {user: "Maksim"}); // label  "Hello Maksim!"

देशी एपीआई में सुधार

आमतौर पर हम मानकों का पालन करना चाहते हैं। लेकिन कभी-कभी मानक पूरी तरह से अनुकूल नहीं होते हैं। DOM बहुत भ्रामक है, और इसे अच्छा बनाने के लिए, आपको इसे एक सुविधाजनक API में लपेटना होगा। विभिन्न पुस्तकालयों द्वारा किए गए कई सुधारों के बावजूद, कुछ चीजों को बेहतर किया जा सकता है:

गेटटर और सेटर
घटना से निपटने में सुधार
कार्यात्मक तरीकों के लिए समर्थन

गेटटर और सेटर

मूल डोम में एक तत्व की विशेषताओं और गुणों की अवधारणा है जो अलग-अलग व्यवहार कर सकती है। मान लीजिए कि पृष्ठ में मार्कअप है:

 <a href="/chemerisuk/better-dom" id="foo" data-test="test">better-dom</a>

देशी डोम की दुश्मनी को समझाने के लिए, आइए इसके साथ थोड़ा काम करते हैं:

 var link = document.getElementById("foo"); link.href; // => "https://github.com/chemerisuk/better-dom" link.getAttribute("href"); // => "/chemerisuk/better-dom" link["data-test"]; // => undefined link.getAttribute("data-test"); // => "test" link.href = "abc"; link.href; // => "https://github.com/abc" link.getAttribute("href"); // => "abc"

इसलिए, विशेषता मान HTML में संबंधित लाइन के बराबर है, जबकि समान नाम वाले तत्व की संपत्ति में विशेष व्यवहार हो सकता है, उदाहरण के लिए, ऊपर के उदाहरण में पूर्ण URL उत्पन्न करना। यह अंतर कभी-कभी भ्रामक हो सकता है।

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

बेहतर-डोम में, चीजें सरल होती हैं: प्रत्येक तत्व में केवल एक स्मार्ट गेट्टर और सेटर होता है ।

 var link = DOM.find("#foo"); link.get("href"); // => "https://github.com/chemerisuk/better-dom" link.set("href", "abc"); link.get("href"); // => "https://github.com/abc" link.get("data-attr"); // => "test"

पहले चरण में, तत्व तत्व की संपत्ति की खोज करते हैं और, यदि इसे परिभाषित किया गया है, तो इसे संचालन के लिए उपयोग करें। अन्यथा, वे इसी विशेषता के साथ काम करते हैं। बूलियन विशेषताओं ( checked , selected , आदि) के लिए, आप बस true या false उपयोग कर सकते हैं। किसी तत्व पर इन गुणों को बदलना संबंधित विशेषता (मूल व्यवहार) को अद्यतन करता है।

घटना से निपटने में सुधार

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

 var button = document.getElementById("foo"); button.addEventListener("click", function(e) { handleButtonClick(e.button); }, false);

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

 var button = DOM.find("#foo"); button.on("click", handleButtonClick, ["button"]);

डिफ़ॉल्ट रूप से, ईवेंट हैंडलर ऐरे को स्वीकार करता है ["target", "defaultPrevented"] , इसलिए इन गुणों को पढ़ने के लिए अंतिम तर्क को जोड़ने की आवश्यकता नहीं है:

 button.on("click", function(target, canceled) { //   });

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

 button._handleButtonClick = function() { alert("click!"); }; button.on("click", "_handleButtonClick"); button.fire("click"); //   "clicked" button._handleButtonClick = null; button.fire("click"); //

निष्कर्ष रूप में, यह ध्यान देने योग्य है कि बेहतर-डोम में click() , focus() , submit() आदि जैसी कोई विधियाँ नहीं हैं, जो मानक में मौजूद हैं और ब्राउज़रों में भिन्न व्यवहार रखती हैं। उन्हें कॉल करने का एकमात्र तरीका fire विधि का उपयोग करना है, जो तब डिफ़ॉल्ट व्यवहार करता है जब कोई भी हैंडलर false लौटता false :

 link.fire("click"); //    link.on("click", function() { return false; }); link.fire("click"); //

कार्यात्मक विधि का समर्थन

ES5 ने सरणियों के लिए कई उपयोगी तरीकों को मानकीकृत किया है जैसे कि map , filter , some , आदि। वे आपको मानकीकृत तरीके से संग्रह पर संचालन करने की अनुमति देते हैं। नतीजतन, आज अंडरस्कोर या लो-डैश जैसी परियोजनाएं हैं जो आपको पुराने ब्राउज़रों में इन विधियों का उपयोग करने की अनुमति देती हैं।

बेहतर-डोम में प्रत्येक तत्व (या संग्रह) में बॉक्स से बाहर के तरीके हैं:

each ( forEach से भिन्न है कि यह undefined बजाय इसे लौटाता है)
some
every
map
filter
reduce[Right]

 var urls, activeLi, linkText; urls = menu.findAll("a").map(function(el) { return el.get("href"); }); activeLi = menu.children().filter(function(el) { return el.hasClass("active"); }); linkText = menu.children().reduce(function(memo, el) { return memo || el.hasClass("active") && el.find("a").get() }, false);

कुछ jQuery के मुद्दों को हल करना

पिछड़ी संगतता को खोए बिना नीचे दी गई अधिकांश समस्याएं jQuery में तय नहीं की जा सकती हैं। एक और कारण एक नया पुस्तकालय बनाने का निर्णय लिया गया।

$ जादू समारोह
कोष्ठक ऑपरेटर मूल्य
return false साथ समस्या
find और findAll

$ जादू समारोह

हर किसी ने कभी सुना है कि फ़ंक्शन $ (डॉलर) "जादू" है। नाम, केवल एक वर्ण से मिलकर, बहुत स्पष्ट नहीं है, फ़ंक्शन भाषा में निर्मित एक बयान की तरह दिखता है। यही कारण है कि अनुभवहीन डेवलपर्स इसे बस जहां कहीं भी जरूरत है, वहां बुलाते हैं।

पर्दे के पीछे, $ एक बहुत जटिल विशेषता है । इसे बार-बार चलाना, विशेष रूप से mousemove या scroll जैसी घटनाओं के कारण, खराब यूआई प्रतिक्रिया हो सकती है।

कई लेख जो कैशिंग jQuery वस्तुओं को बढ़ावा देते हैं, के बावजूद, डेवलपर्स $ एम्बेड करना जारी रखते हैं। ऐसा इसलिए है क्योंकि लाइब्रेरी का सिंटैक्स इस कोडिंग शैली को बढ़ावा देता है।

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

 $("a"); // =>   ,    “a” $("<a>"); // =>   <a>  jQuery

$ फ़ंक्शन की जिम्मेदारी के बेहतर-डोम क्षेत्रों में कई विधियों द्वारा कवर किया जाता है : find[All] और DOM.create । सीएसएस चयनकर्ता द्वारा तत्वों की खोज करने के find[All] विधियों का उपयोग किया जाता है। DOM.create मेमोरी में नए आइटम बनाता है। फ़ंक्शन नाम स्पष्ट रूप से कहते हैं कि ये कार्य क्या करते हैं।

वर्गाकार कोष्ठक संचालक का मान

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

 var links = $("a"); links[0].on("click", function() { ... }); // ! $(links[0]).on("click", function() { ... }); //

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

बेहतर-डोम में, वर्ग ब्रैकेट ऑपरेटर एक पुस्तकालय वस्तु देता है, ताकि आप मूल तत्वों के बारे में भूल सकें। उन्हें एक्सेस करने का एकमात्र कानूनी तरीका विशेष legacy विधि का उपयोग करना है।

 var foo = DOM.find("#foo"); foo.legacy(function(node) { //   Hammer   swipe Hammer(node).on("swipe", function(e) { //   swipe }); });

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

वापसी के साथ समस्या

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

यहाँ कई समस्याएं हैं:

कॉलिंग stopPropagation() अपने आप पर, संगतता समस्याएं पैदा कर सकता है, जैसा कि यह अन्य श्रोताओं को इस तरह के आयोजन का काम करने की क्षमता को तोड़ देता है
अधिकांश डेवलपर्स (यहां तक कि अनुभवी भी) इस व्यवहार की उम्मीद नहीं करते हैं

यह स्पष्ट नहीं है कि jQuery समुदाय ने मानकों के खिलाफ जाने का फैसला क्यों किया। और बेहतर-डोम इस त्रुटि को दोहराने नहीं जा रहा है: ईवेंट हैंडलर के अंदर return false केवल अपेक्षित रूप से preventDefault() ।

खोजो और पाओ

आइटम ढूँढना ब्राउज़र में सबसे महंगा संचालन में से एक है। इसे लागू करने के लिए दो मूल कार्यों का उपयोग किया जा सकता है: querySelector और querySelectorAll । दोनों के बीच अंतर यह है कि पहले मैच के बाद खोज बंद हो जाती है।

यह सुविधा उपयुक्त मामलों में पुनरावृत्तियों की संख्या को काफी कम कर सकती है। मेरे परीक्षणों में, गति में लाभ 20 गुना तक हो सकता है । आप यह भी उम्मीद कर सकते हैं कि दस्तावेज़ के पेड़ के आकार के आधार पर अंतराल बढ़ता है।

jQuery में एक find विधि है जो सामान्य रूप से querySelectorAll का उपयोग querySelectorAll है। आज तक, कोई ऐसा तरीका नहीं है जो केवल पहले उपयुक्त तत्व को खोजने के लिए querySelector का उपयोग करेगा।

बेहतर-डोम में दो अलग-अलग विधियाँ हैं: find और findAll । वे आपको ऊपर दिए गए querySelector -optimization का उपयोग करने की अनुमति देते हैं। संभावित लाभ का आकलन करने के लिए, मैंने अंतिम वाणिज्यिक परियोजना के स्रोत कोड में प्रविष्टियों की संख्या से चयन किया:

find - 11 फाइलों में 103 मैच
findAll - 4 फाइलों में 14 findAll

निश्चित रूप से, find विधि अधिक लोकप्रिय है। इसका मतलब यह है कि querySelector -optimization ज्यादातर मामलों में होता है, इसलिए, यह क्लाइंट पर कोड के प्रदर्शन में एक ठोस लाभ दे सकता है।

निष्कर्ष

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

विकास के दौरान, मुझे एक महत्वपूर्ण बात का एहसास हुआ: यदि वर्तमान मानक पूरी तरह से संतुष्ट नहीं हैं या यदि आपके पास बेहतर करने के लिए विचार हैं, तो बस लागू करें और साबित करें कि वे काम करते हैं । और यह बहुत मजेदार है!

बेहतर-डोम लाइब्रेरी के बारे में अधिक जानकारी हमेशा GitHub पर मिल सकती है ।

DOM के साथ काम करने के लिए एक बेहतर JavaScript लाइब्रेरी बनाने के बारे में