इंटरसेक्शन ऑब्ज़र्वर से आपको पता चलता है कि मॉनिटर किया जा रहा कोई एलिमेंट कब ब्राउज़र के व्यूपोर्ट में शामिल होता है या उससे बाहर आता है.
मान लें कि आपको यह ट्रैक करना है कि आपके डीओएम का कोई एलिमेंट, दिखने वाले व्यूपोर्ट में कब आता है. ऐसा इसलिए किया जा सकता है, ताकि आप सही समय पर इमेज को लेज़ी-लोड कर सकें या आपके लिए यह जानना ज़रूरी हो कि उपयोगकर्ता वाकई किसी विज्ञापन बैनर में देख रहा है या नहीं. ऐसा करने के लिए, स्क्रोल करने की सुविधा को चालू करें. इसके अलावा, समय-समय पर टाइमर का इस्तेमाल करके और getBoundingClientRect() पर कॉल करके भी ऐसा किया जा सकता है
उस एलिमेंट पर.
हालांकि, यह तरीका बहुत धीमा होता है, क्योंकि getBoundingClientRect() को किया जाने वाला हर कॉल, ब्राउज़र को पूरे पेज को फिर से लेआउट करने के लिए मजबूर करता है और इससे आपकी वेबसाइट में काफ़ी जैंक पैदा होता है. जब आपको पता होता है कि आपकी साइट किसी iframe में लोड की जा रही है और आपको यह जानना है कि उपयोगकर्ता को कोई एलिमेंट कब दिख सकता है, तो ऐसे मामले हो सकते हैं. सिंगल ऑरिजिन मॉडल और ब्राउज़र आपको उस वेब पेज से कोई भी डेटा ऐक्सेस नहीं करने देंगे जिसमें iframe है. यह उन विज्ञापनों के लिए एक सामान्य समस्या है, जो iframe का इस्तेमाल करके अक्सर लोड किए जाते हैं.
विज़िबिलिटी की इस जांच को बेहतर बनाने के लिए, IntersectionObserver को डिज़ाइन किया गया है. साथ ही, इसे सभी मॉडर्न ब्राउज़र में उपलब्ध कराया गया है. IntersectionObserver आपको इसकी जानकारी देता है कि निगरानी में रखा गया कोई एलिमेंट कब ब्राउज़र के व्यूपोर्ट में आता है या उससे बाहर निकलें.
IntersectionObserver बनाने का तरीका
एपीआई बहुत छोटा है और इसकी सबसे अच्छी जानकारी एक उदाहरण का इस्तेमाल करके दी गई है:
const io = new IntersectionObserver(entries => {
console.log(entries);
}, {
/* Using default options. Details below */
});
// Start observing an element
io.observe(element);
// Stop observing an element
// io.unobserve(element);
// Disable entire IntersectionObserver
// io.disconnect();
IntersectionObserver के लिए डिफ़ॉल्ट विकल्पों का इस्तेमाल करते समय, आपके कॉलबैक को तब कॉल किया जाएगा, जब एलिमेंट का कुछ हद तक व्यू में आना और वह व्यूपोर्ट से पूरी तरह से बाहर निकल जाए.
अगर आपको एक से ज़्यादा एलिमेंट को ट्रैक करना ज़रूरी है, तो observe() को कई बार कॉल करके एक ही IntersectionObserver इंस्टेंस का इस्तेमाल करके, अलग-अलग एलिमेंट का निरीक्षण किया जा सकता है.
आपके कॉलबैक को एक entries पैरामीटर पास किया जाता है, जो IntersectionObserverEntry ऑब्जेक्ट का कलेक्शन होता है. ऐसे हर ऑब्जेक्ट में, मॉनिटर किए गए किसी एलिमेंट के लिए, अपडेट किया गया इंटरसेक्शन डेटा शामिल होता है.
🔽[IntersectionObserverEntry]
time: 3893.92
🔽rootBounds: ClientRect
bottom: 920
height: 1024
left: 0
right: 1024
top: 0
width: 920
🔽boundingClientRect: ClientRect
// ...
🔽intersectionRect: ClientRect
// ...
intersectionRatio: 0.54
🔽target: div#observee
// ...
rootBounds रूट एलिमेंट पर getBoundingClientRect() को कॉल करने का नतीजा है, जो डिफ़ॉल्ट रूप से व्यूपोर्ट होता है. boundingClientRect, मॉनिटर किए गए एलिमेंट पर कॉल किए गए getBoundingClientRect() का नतीजा है. intersectionRect इन दो रेक्टैंगल को जोड़ता है. इससे आपको यह पता चलता है कि एलिमेंट का कौनसा हिस्सा दिख रहा है. intersectionRatio काफ़ी हद तक मिलता-जुलता है. इससे आपको पता चलता है कि एलिमेंट का कितना हिस्सा दिख रहा है. इस जानकारी के साथ, अब ऐसेट को स्क्रीन पर दिखने से पहले ही लोड होने जैसी सुविधाओं को लागू किया जा सकता है. बेहतर तरीके से.
IntersectionObserver अपना डेटा एसिंक्रोनस रूप से डिलीवर करता है और आपका कॉलबैक कोड मुख्य थ्रेड में चलेगा. इसके अलावा, स्पेसिफ़िकेशन में यह बताया गया है कि IntersectionObserver लागू करने के लिए requestIdleCallback() का इस्तेमाल करना चाहिए. इसका मतलब है कि आपने जो कॉलबैक किया है उसकी प्राथमिकता कम है और उसे ब्राउज़र तब करेगा, जब उसे इस्तेमाल न किया जा रहा हो. यह एक सोच-समझकर डिज़ाइन किया गया फ़ैसला है.
स्क्रोल करने वाले divs
मुझे एलिमेंट में स्क्रोल करना ज़्यादा पसंद नहीं है, लेकिन मुझे न तो कोई फ़ैसला लेना है और न ही IntersectionObserver. options ऑब्जेक्ट में root विकल्प होता है. इससे व्यूपोर्ट के किसी विकल्प को रूट के तौर पर सेट किया जा सकता है. इस बात का ध्यान रखना ज़रूरी है कि root, मॉनिटर किए गए सभी एलिमेंट का पूर्वज होना चाहिए.
सभी चीज़ों का प्रतिच्छेदन करें!
नहीं! खराब डेवलपर! यह आपके उपयोगकर्ता के सीपीयू साइकल के इस्तेमाल को लेकर सजग नहीं है. एक उदाहरण के तौर पर, इनफ़ाइनाइट स्क्रोलर के बारे में सोचते हैं: इस स्थिति में, डीओएम में सेंटिनल जोड़ना और उनकी निगरानी (और रीसाइकल!) करना बिलकुल सही है. आपको इनफ़ाइनाइट स्क्रोलर में, आखिरी आइटम के पास सेंटिनल जोड़ना चाहिए. जब वह सेंटिनल व्यू में आता है, तो डेटा लोड करने, अगले आइटम बनाने, उन्हें DOM में अटैच करने, और उसी हिसाब से सेंटिनल की जगह बदलने के लिए, कॉलबैक का इस्तेमाल किया जा सकता है. अगर आपने सेंटिनल को सही तरीके से रीसाइकल किया है, तो observe() को कॉल करने की ज़रूरत नहीं पड़ेगी. IntersectionObserver काम करता रहता है.
कृपया और अपडेट दें
जैसा कि पहले बताया गया है, कॉलबैक एक बार तब ट्रिगर होगा, जब मॉनिटर किया गया एलिमेंट पूरी तरह से व्यू में नहीं आता है और दूसरी बार, जब वह व्यूपोर्ट से बाहर निकल जाता है. इस तरह, IntersectionObserver आपको "क्या एलिमेंट X व्यू में है?" का जवाब देता है. हालांकि, हो सकता है कि कुछ मामलों में यह काफ़ी न हो.
ऐसी ही स्थिति में threshold विकल्प इस्तेमाल होता है. इसकी मदद से, intersectionRatio थ्रेशोल्ड का कलेक्शन तय किया जा सकता है. जब भी intersectionRatio इनमें से किसी एक वैल्यू को पार करेगा, तब आपके कॉलबैक को कॉल किया जाएगा. threshold का डिफ़ॉल्ट मान [0] है, जो डिफ़ॉल्ट व्यवहार के बारे में बताता है. अगर हम threshold को [0, 0.25, 0.5, 0.75, 1] में बदलते हैं, तो जब भी एलिमेंट का एक चौथाई हिस्सा दिखेगा, तब हमें इसकी सूचना मिलेगी:
क्या कोई और विकल्प है?
फ़िलहाल, ऊपर दिए गए विकल्पों में से सिर्फ़ एक और विकल्प मौजूद है. rootMargin आपको रूट के लिए मार्जिन तय करने की सुविधा देता है. इससे आप चौराहों के लिए इस्तेमाल किए जाने वाले एरिया को बढ़ा या छोटा कर सकते हैं. ये मार्जिन, सीएसएस शैली वाली स्ट्रिंग, á la "10px 20px 30px 40px", का इस्तेमाल करके तय किए जाते हैं. इसमें ऊपर, दाएं, नीचे, और बाएं मार्जिन को क्रम से बताया जाता है. खास जानकारी देने के लिए, IntersectionObserver विकल्प स्ट्रक्चर में ये विकल्प मिलते हैं:
new IntersectionObserver(entries => {/* … */}, {
// The root to use for intersection.
// If not provided, use the top-level document's viewport.
root: null,
// Same as margin, can be 1, 2, 3 or 4 components, possibly negative lengths.
// If an explicit root element is specified, components may be percentages of the
// root element size. If no explicit root element is specified, using a
// percentage is an error.
rootMargin: "0px",
// Threshold(s) at which to trigger callback, specified as a ratio, or list of
// ratios, of (visible area / total area) of the observed element (hence all
// entries must be in the range [0, 1]). Callback will be invoked when the
// visible ratio of the observed element crosses a threshold in the list.
threshold: [0],
});
<iframe> का मैजिक
IntersectionObserver, खास तौर पर विज्ञापन सेवाओं और सोशल नेटवर्क के विजेट को ध्यान में रखकर बनाए गए हैं. ये विजेट अक्सर <iframe> एलिमेंट का इस्तेमाल करते हैं. इसलिए, उन्हें यह जानने से फ़ायदा हो सकता है कि वे दिख रहे हैं या नहीं. अगर <iframe> किसी एलिमेंट को देखता है, तो <iframe> को स्क्रोल करने और <iframe> वाली विंडो को स्क्रोल करने से कॉलबैक सही समय पर ट्रिगर हो जाएगा. हालांकि, बाद वाले मामले में rootBounds को null पर सेट किया जाएगा, ताकि सभी ऑरिजिन में डेटा लीक होने से बचा जा सके.
IntersectionObserver किस बारे में नहीं है?
यह ध्यान रखें कि IntersectionObserver जान-बूझकर पिक्सल सटीक नहीं है और न ही इंतज़ार का समय कम है. स्क्रोल पर निर्भर ऐनिमेशन जैसे कामों को लागू करने में उनका इस्तेमाल करना मुमकिन नहीं है. इसकी वजह यह है कि जब तक उनका इस्तेमाल शुरू होगा, डेटा पुराना हो जाएगा. जानकारी देने वाले में, IntersectionObserver के इस्तेमाल के मूल उदाहरणों के बारे में ज़्यादा जानकारी दी गई है.
कॉलबैक में कितना काम किया जा सकता है?
कम अवधि का और मज़ेदार: कॉलबैक में ज़्यादा समय देने से, आपका ऐप्लिकेशन काम करने में देरी कर सकता है—सभी सामान्य तरीके लागू होते हैं.
आगे बढ़ें और आपके तत्वों को काट दें
IntersectionObserver के लिए ब्राउज़र समर्थन अच्छा है, क्योंकि यह सभी आधुनिक ब्राउज़र में उपलब्ध है. अगर ज़रूरी हो, तो पुराने ब्राउज़र में पॉलीफ़िल का इस्तेमाल किया जा सकता है. यह WICG की रिपॉज़िटरी में भी उपलब्ध है. ज़ाहिर है, आपको उस पॉलीफ़िल का इस्तेमाल करने पर परफ़ॉर्मेंस के फ़ायदे नहीं मिलेंगे जो मूल रूप से लागू करने पर मिलता है.
अब से IntersectionObserver को इस्तेमाल करना शुरू किया जा सकता है! हमें बताएं कि आपने क्या सोचा.