इवेंट श्रोता और वेब वर्कर

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

जिस क्षण मैं सब कुछ समझ गया

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

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

यहां कोड का एक उदाहरण दिया गया है जिसे आप यहां याद कर सकते हैं:

const calculateResultsButton = document.getElementById('calculateResultsButton'); const openMenuButton = document.getElementById('#openMenuButton'); const resultBox = document.getElementById('resultBox'); calculateResultsButton.addEventListener('click', (e) => {     // "    -, ,   ,     //   DOM   ?"     const result = performLongRunningCalculation();     resultBox.innerText = result; }); openMenuButton.addEventListener('click', (e) => {     //      . }); 

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

पृष्ठ को "धीमा" कैसे करें

यहाँ एक CodePen परियोजना है जो ऊपर प्रदर्शित हो रही है।


एक ऐसी स्थिति का प्रदर्शन करने वाली परियोजना जिसमें पृष्ठ धीमे हैं

Freeze बटन दबाने से एप्लिकेशन को सिंक्रोनस कार्य को हल करना शुरू हो जाता है। यह सब 3 सेकंड लेता है (यह लंबी गणना के प्रदर्शन को अनुकरण करता है)। यदि एक ही समय में Increment बटन पर क्लिक करें, तो जब तक 3 सेकंड बीत चुके हैं, तब तक Click Count फ़ील्ड में मूल्य अपडेट नहीं किया जाएगा। Increment पर क्लिकों की संख्या के अनुरूप एक नया मान इस क्षेत्र को केवल तीन सेकंड बीतने के बाद लिखा जाएगा। एक ठहराव के दौरान मुख्य धारा अवरुद्ध है। नतीजतन, एप्लिकेशन विंडो में सब कुछ निष्क्रिय दिखता है। एप्लिकेशन इंटरफ़ेस जमे हुए है। "ठंड" की प्रक्रिया में उत्पन्न होने वाली घटनाएं मुख्य धारा के संसाधनों का उपयोग करने के अवसर की प्रतीक्षा कर रही हैं।

यदि आप Freeze पर क्लिक करते हैं और resize me! कोशिश करते हैं resize me! , फिर, फिर से, जब तक तीन सेकंड बीत चुके हैं, तब तक फ़ील्ड का आकार नहीं बदलेगा। और उसके बाद, क्षेत्र का आकार, हालांकि, बदल जाएगा, लेकिन इंटरफ़ेस में किसी भी "चिकनाई" के बारे में बात करने की कोई आवश्यकता नहीं है।

ईवेंट श्रोताओं पहली नज़र में लग सकता है की तुलना में एक बहुत बड़ी घटना है

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

 Array  .from([document, ...document.querySelectorAll('*')])  .reduce((accumulator, node) => {    let listeners = getEventListeners(node);    for (let property in listeners) {      accumulator = accumulator + listeners[property].length    }    return accumulator;  }, 0); 

मैंने इस स्क्रिप्ट को अलग-अलग पन्नों पर चलाया और उन पर श्रोताओं की संख्या के बारे में पता लगाया। मेरे प्रयोग के परिणाम निम्न तालिका में दिखाए गए हैं।

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

वेब कर्मचारियों के साथ "ब्रेक" से छुटकारा पाएं

उपरोक्त सभी को देखते हुए, आइए पिछले उदाहरण को फिर से लिखें। यहाँ उसका नया संस्करण है यह बिल्कुल पुराने जैसा दिखता है, लेकिन इसके अंदर अलग तरह से व्यवस्थित किया गया है। अर्थात्, अब ऑपरेशन जो मुख्य धागे को ब्लॉक करता था, उसे अपने स्वयं के धागे में स्थानांतरित कर दिया गया है। यदि आप इस उदाहरण के साथ पिछले एक के साथ ही करते हैं, तो आप गंभीर सकारात्मक अंतर देख सकते हैं। अर्थात्, यदि Freeze बटन Increment पर क्लिक करने के बाद, Click Count क्षेत्र अपडेट किया जाएगा (वेब ​​कार्यकर्ता समाप्त होने के बाद, किसी भी स्थिति में, संख्या 1 Click Count मूल्य में जोड़ा जाएगा)। वही resize me! लिए जाता resize me! । एक अलग थ्रेड में चल रहा कोड ईवेंट श्रोताओं को ब्लॉक नहीं करता है। यह पृष्ठ के सभी तत्वों को एक ऑपरेशन के निष्पादन के दौरान भी चालू रखने की अनुमति देता है जो पहले केवल पृष्ठ को "फ्रीज" करता है।

इस उदाहरण के लिए यहाँ JS कोड है:

 const button1 = document.getElementById('button1'); const button2 = document.getElementById('button2'); const count = document.getElementById('count'); const workerScript = `  function pause(ms) {    let time = new Date();    while ((new Date()) - time <= ms) {}               }  self.onmessage = function(e) {    pause(e.data);    self.postMessage('Process complete!');  } `; const blob = new Blob([  workerScript, ], {type: "text/javascipt"}); const worker = new Worker(window.URL.createObjectURL(blob)); const bumpCount = () => {  count.innerText = Number(count.innerText) + 1; } worker.onmessage = function(e) {  console.log(e.data);  bumpCount(); } button1.addEventListener('click', async function () {  worker.postMessage(3000); }); button2.addEventListener('click', function () {  bumpCount(); }); 

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

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

परिणाम

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

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

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

प्रिय पाठकों! क्या आप अपनी परियोजनाओं में वेब कर्मचारियों का उपयोग करते हैं?