इनपुट, कंपोज़िटर को मिलने वाला है
यह 4 भागों वाली ब्लॉग सीरीज़ में से आखिरी है, जिसमें Chrome में जानकारी दी गई है; पता लगाया जा रहा है कि यह कैसे मैनेज करता है हमारा कोड है. पिछली पोस्ट में, हमने रेंडरिंग की प्रोसेस पर गौर किया था और कंपोज़िटर के बारे में जाना. इस पोस्ट में, हम यह देखें कि कैसे कंपोज़िटर, उपयोगकर्ता का इनपुट मिलने पर बिना किसी रुकावट के इंटरैक्शन को चालू कर रहा है.
ब्राउज़र के हिसाब से इवेंट डालें
"इनपुट इवेंट" सुनाई देने पर हो सकता है कि आप टेक्स्टबॉक्स या माउस क्लिक में टाइप करने के बारे में सोचते हों, लेकिन ब्राउज़र के नज़रिए से, इनपुट का मतलब है, उपयोगकर्ता का कोई भी जेस्चर. माउस व्हील स्क्रोल एक इनपुट है इवेंट और टच या माउस ओवर भी एक इनपुट इवेंट है.
जब स्क्रीन पर टच करने जैसा उपयोगकर्ता जेस्चर होता है, तो ब्राउज़र प्रोसेस वह होती है जो
हाथ के जेस्चर का इस्तेमाल करें. हालांकि, ब्राउज़र प्रोसेस को सिर्फ़ यह जानकारी है कि जेस्चर कहां से शुरू हुआ
टैब में मौजूद कॉन्टेंट को रेंडर करने वाली प्रोसेस अपने-आप मैनेज करती है. इसलिए ब्राउज़र प्रोसेस, इवेंट को
रेंडरर प्रोसेस के लिए इसके कोऑर्डिनेट और टाइप (जैसे कि touchstart
). रेंडरर प्रोसेस,
इवेंट के टारगेट को खोजकर और अटैच किए गए इवेंट लिसनर को चलाकर इवेंट का सही तरीके से इस्तेमाल किया जा सकता है.
कंपोज़िटर को इनपुट इवेंट मिलते हैं
पिछली पोस्ट में हमने देखा कि कैसे कंपोज़िटर, कंपोज़िट करके आसानी से स्क्रोल करने की प्रोसेस को मैनेज कर सकता है रास्टराइज़्ड लेयर. अगर पेज से कोई भी इनपुट इवेंट लिसनर अटैच नहीं है, तो कंपोज़िटर थ्रेड ये काम कर सकता है: मुख्य थ्रेड से पूरी तरह अलग एक नया कंपोज़िट फ़्रेम बनाना. लेकिन क्या होगा अगर कोई इवेंट श्रोताओं को पेज से अटैच किया गया था? कंपोज़िटर थ्रेड को यह कैसे पता चलेगा कि इवेंट की ज़रूरत है या नहीं संभालकर रखना चाहिए?
स्क्रोल न किए जा सकने वाले हिस्से को समझना
JavaScript चलाना मुख्य थ्रेड का काम होता है, इसलिए जब किसी पेज को कंपोज़िट किया जाता है, तो कंपोज़िटर थ्रेड यह पेज के उस क्षेत्र को मार्क करता है जिसमें इवेंट हैंडलर को "गैर-तेज़ स्क्रोल करने वाला क्षेत्र" के तौर पर जोड़ा जाता है. इन्होंने बदलाव किया है इस जानकारी के होने पर कंपोज़िटर थ्रेड, इनपुट इवेंट को मुख्य थ्रेड में ज़रूर भेज पाएगा ऐसा तब होगा, जब इवेंट उस इलाके में होगा. अगर इनपुट इवेंट इस इलाके के बाहर से आता है, तो मुख्य थ्रेड की इंतज़ार किए बिना, कंपोज़िटर थ्रेड, नए फ़्रेम कंपोज़िट पर ले जाती है.
इवेंट हैंडलर लिखते समय सावधान रहें
वेब डेवलपमेंट में इवेंट मैनेज करने का एक आम पैटर्न, इवेंट डेलिगेशन है. इवेंट बबल के बाद से, आप सबसे ऊपर के एलिमेंट पर एक इवेंट हैंडलर अटैच कर सकते हैं और इवेंट टारगेट के आधार पर टास्क सौंप सकते हैं. आपने लोगों तक पहुंचाया मुफ़्त में शायद इसने नीचे दिए गए कोड की तरह देखा या लिखा होगा.
document.body.addEventListener('touchstart', event => {
if (event.target === area) {
event.preventDefault();
}
});
आपको सभी एलिमेंट के लिए सिर्फ़ एक इवेंट हैंडलर लिखना होगा, इसलिए इस इवेंट के लिए एर्गोनॉमिक्स डेलिगेशन पैटर्न आकर्षक है. हालांकि, यदि आप ब्राउज़र के बिंदु से इस कोड को देखते हैं देखने के लिए, अब पूरा पेज एक ऐसे क्षेत्र के रूप में मार्क कर दिया गया है जिसे तेज़ी से स्क्रोल नहीं किया जा सकता. इसका मतलब यह है कि भले ही ऐप्लिकेशन को पेज के कुछ हिस्सों से इनपुट लेने में कोई दिक्कत नहीं है, इसलिए कंपोज़िटर थ्रेड को मुख्य थ्रेड से संपर्क करें और हर बार किसी इनपुट इवेंट के आने का इंतज़ार करें. इसलिए, कंपोज़िटर की आसानी से स्क्रोल करने की क्षमता खत्म हो गई है.
ऐसा होने से रोकने के लिए, अपने इवेंट में passive: true
विकल्प पास करें
लिसनर. यह उस ब्राउज़र को संकेत देता है कि आपको अब भी मुख्य थ्रेड में इवेंट को सुनना है,
लेकिन कंपोज़िटर आगे बढ़कर नया फ़्रेम भी बना सकते हैं.
document.body.addEventListener('touchstart', event => {
if (event.target === area) {
event.preventDefault()
}
}, {passive: true});
यह देखना कि इवेंट को रद्द किया जा सकता है या नहीं
मान लें कि आपके पेज में एक बॉक्स है, जिसमें आपको स्क्रोल की दिशा को सिर्फ़ हॉरिज़ॉन्टल स्क्रोलिंग तक सीमित करना है.
पॉइंटर इवेंट में passive: true
विकल्प का इस्तेमाल करने का मतलब है कि पेज को स्क्रोल करना आसान हो सकता है, लेकिन
वर्टिकल स्क्रोलिंग, शायद उस समय तक शुरू हो चुकी हो जब आपने preventDefault
को फ़ॉलो किया हो
जाने की दिशा में स्क्रोल करें. event.cancelable
तरीके का इस्तेमाल करके, इस गड़बड़ी की जांच की जा सकती है.
document.body.addEventListener('pointermove', event => {
if (event.cancelable) {
event.preventDefault(); // block the native scroll
/*
* do what you want the application to do here
*/
}
}, {passive: true});
इसके अलावा, इवेंट हैंडलर को पूरी तरह से हटाने के लिए, touch-action
जैसे सीएसएस नियम का इस्तेमाल किया जा सकता है.
#area {
touch-action: pan-x;
}
इवेंट टारगेट का पता लगाना
जब कंपोज़िटर थ्रेड मुख्य थ्रेड पर कोई इनपुट इवेंट भेजता है, तो सबसे पहले चलाने के लिए हिट होता है की जांच करें. हिट टेस्ट, रेंडरिंग के दौरान जनरेट हुआ पेंट रिकॉर्ड डेटा इस्तेमाल करता है जिस बिंदु निर्देशांक में वह घटना हुई है उसके नीचे क्या है, यह जानने की प्रक्रिया.
इवेंट की जानकारी कम से कम मुख्य थ्रेड में भेजी जा रही है
पिछली पोस्ट में, हमने बताया था कि सामान्य डिसप्ले एक सेकंड में 60 बार स्क्रीन को कैसे रीफ़्रेश करता है और ताकि हमें बेहतरीन ऐनिमेशन बनाए रखने में मदद मिले. इनपुट के लिए, सामान्य टचस्क्रीन डिवाइस एक सेकंड में 60 से 120 बार टच इवेंट देता है. साथ ही, सामान्य माउस एक सेकंड में 100 बार इवेंट देता है सेकंड. स्क्रीन को रीफ़्रेश किए जाने की तुलना में, इनपुट इवेंट की फ़िडेलिटी ज़्यादा है.
अगर touchmove
जैसे, लगातार चलने वाले इवेंट को एक सेकंड में 120 बार मुख्य थ्रेड को भेजा गया था, तो वह
ट्रिगर कई बार हिट टेस्ट और JavaScript एक्ज़ीक्यूशन को ट्रिगर करने की तुलना में
तो स्क्रीन को रीफ़्रेश किया जा सकता है.
मुख्य थ्रेड पर ज़्यादा आने वाले कॉल को कम करने के लिए, Chrome लगातार इवेंट को इकट्ठा करता है (जैसे कि
wheel
, mousewheel
, mousemove
, pointermove
, touchmove
) और भेजने में देरी इस समय तक होगी
अगले requestAnimationFrame
से ठीक पहले.
अलग-अलग इवेंट, जैसे कि keydown
, keyup
, mouseup
, mousedown
, touchstart
, और touchend
तुरंत भेज दिए जाते हैं.
इंट्रा-फ़्रेम इवेंट पाने के लिए getCoalescedEvents
का इस्तेमाल करें
ज़्यादातर वेब ऐप्लिकेशन के लिए, उपयोगकर्ताओं को बेहतर अनुभव देने के लिए, इकट्ठा किए गए इवेंट काफ़ी होने चाहिए.
हालांकि, अगर आप ऐप्लिकेशन ड्रॉइंग करने जैसी चीज़ें बना रहे हैं और
touchmove
निर्देशांक, समान रेखा खींचने के लिए आप निर्देशांकों के बीच में खो सकते हैं. ऐसी स्थिति में,
उनके बारे में जानकारी पाने के लिए, पॉइंटर इवेंट में getCoalescedEvents
तरीके का इस्तेमाल किया जा सकता है
इकट्ठा हुए इवेंट.
window.addEventListener('pointermove', event => {
const events = event.getCoalescedEvents();
for (let event of events) {
const x = event.pageX;
const y = event.pageY;
// draw a line using x and y coordinates.
}
});
अगले चरण
इस सीरीज़ में, हमने वेब ब्राउज़र के अंदरूनी काम के बारे में बताया है. अगर आपने कभी भी यह नहीं सोचा है कि
DevTools आपके इवेंट हैंडलर पर {passive: true}
जोड़ने या async
लिखने का सुझाव देता है
एट्रिब्यूट इस्तेमाल किया है, तो मुझे उम्मीद है कि इस सीरीज़ से आपको पता चलेगा कि ब्राउज़र को उनकी ज़रूरत क्यों है
तेज़ और आसान वेब अनुभव देने के लिए जानकारी.
लाइटहाउस का इस्तेमाल करें
अगर आपको अपने कोड को ब्राउज़र के हिसाब से बनाना है, लेकिन आपको नहीं पता कि शुरुआत कहां से करनी है, तो Lighthouse एक ऐसा टूल है जो किसी भी वेबसाइट का ऑडिट करता है और आपको रिपोर्ट करें कि किस तरह के सुधार की ज़रूरत है और किन चीज़ों में सुधार की ज़रूरत है. ऑडिट की सूची को पढ़ना इससे आपको यह जानने में भी मदद मिलती है कि ब्राउज़र किस तरह की चीज़ों के बारे में सोच रहा है.
परफ़ॉर्मेंस मेज़र करने का तरीका जानें
अलग-अलग साइटों के लिए, परफ़ॉर्मेंस में बदलाव करने वाले टूल अलग-अलग हो सकते हैं. इसलिए, परफ़ॉर्मेंस का आकलन करना ज़रूरी है की समीक्षा करें और तय करें कि आपकी साइट के लिए सबसे सही क्या है. Chrome DevTools टीम के पास कुछ ट्यूटोरियल उपलब्ध हैं अपनी साइट की परफ़ॉर्मेंस को मापने का तरीका जानें.
अपनी साइट में सुविधा नीति जोड़ें
एक और चरण पूरा करने के लिए, सुविधा की नीति नई सुविधा है
वेब प्लैटफ़ॉर्म की सुविधा देता है, जो प्रोजेक्ट बनाते समय आपके लिए कारगर साबित हो सकती है. चालू किया जा रहा है
सुविधा से जुड़ी नीति, आपके ऐप्लिकेशन के खास व्यवहार की गारंटी देती है और आपको गलतियां करने से रोकती है.
उदाहरण के लिए, अगर आपको यह पक्का करना है कि आपका ऐप्लिकेशन पार्स करने की प्रोसेस को कभी ब्लॉक न करे, तो अपने ऐप्लिकेशन को
सिंक्रोनस स्क्रिप्ट नीति. sync-script: 'none'
के चालू होने पर, पार्सर को ब्लॉक करने वाला JavaScript
उसे एक्ज़ीक्यूट करने से रोका जाएगा. यह आपके किसी भी कोड को पार्सर ब्लॉक करने से रोकता है, और
ब्राउज़र को पार्सर रोकने के बारे में चिंता करने की आवश्यकता नहीं है.
आखिर में खास जानकारी
जब मैंने वेबसाइटें बनाना शुरू किया, तब मैंने बस इस बात पर ध्यान दिया कि मैं अपना कोड कैसे लिखूं और क्या मुझे कम समय में ज़्यादा काम करना चाहिए. ये चीज़ें अहम हैं, लेकिन हमें यह भी सोचना चाहिए कि ब्राउज़र हमारे द्वारा लिखे गए कोड को लेता है. मॉडर्न ब्राउज़र नए और बेहतर तरीके से निवेश करना जारी रखते हैं उपयोगकर्ताओं को बेहतर वेब अनुभव उपलब्ध कराना. अपने कोड को व्यवस्थित करके ब्राउज़र के प्रति अच्छा व्यवहार करना, और उपयोगकर्ता अनुभव को बेहतर बनाता है. मुझे उम्मीद है कि ब्राउज़र का इस्तेमाल बेहतर तरीके से करने की दौड़ में आप भी मेरे साथ होंगे!
उन सभी लोगों को बहुत-बहुत धन्यवाद जिन्होंने इस सीरीज़ के शुरुआती ड्राफ़्ट की समीक्षा की है. इसमें इनके अलावा, और भी चीज़ें शामिल हो सकती हैं इनके लिए: एलेक्स रसेल, पॉल आइरिश, मेगिन कार्नी, एरिक बिडलमैन, मैथियास बायनेंस, अदी ओस्मानी, किनुको यसुडा, नास्को ओस्कोव, और चार्ली रीस.
क्या आपको यह सीरीज़ पसंद आई? अगर आगे की पोस्ट के लिए आपके पास कोई सवाल या सुझाव है, तो मुझे आपके सुझाव, शिकायत या राय जानकर, नीचे टिप्पणी वाले सेक्शन या @kosamari की मदद से खुशी होगी Twitter पर.