View Transition API, वेब डेवलपमेंट में एक अहम बदलाव है. भले ही, आपकी वेबसाइट एक पेज वाली हो या कई पेजों वाली, इस बेहतरीन एपीआई की मदद से व्यू के बीच आसानी से ट्रांज़िशन किया जा सकता है. इससे, उपयोगकर्ताओं को नेटिव जैसे अनुभव मिलते हैं, जो उन्हें आपके प्रॉडक्ट या सेवाओं के प्रति आकर्षित करते हैं. फ़िलहाल, यह सुविधा Chrome पर उपलब्ध है. जल्द ही, यह Safari पर भी उपलब्ध होगी.
ज़्यादा से ज़्यादा लोग व्यू ट्रांज़िशन एपीआई के बारे में जानने लगे हैं. इसलिए, कुछ गलतफ़हमियों को दूर करने का समय आ गया है.
गलतफ़हमी 1: View Transition API, स्क्रीनशॉट लेता है
व्यू ट्रांज़िशन चलाने पर, एपीआई कॉन्टेंट की पुरानी और नई स्थिति के स्नैपशॉट लेता है. इसके बाद, इन स्नैपशॉट को ऐनिमेशन में बदल दिया जाता है. इस बारे में ज़्यादा जानकारी, दस्तावेज़ के "ये ट्रांज़िशन कैसे काम करते हैं" सेक्शन में दी गई है.
पुराने स्नैपशॉट के लिए, स्क्रीनशॉट शब्द का इस्तेमाल किया जा सकता है. हालांकि, नया स्नैपशॉट कोई स्क्रीनशॉट नहीं है, बल्कि यह नोड का लाइव वर्शन होता है. इसे बदले गए एलिमेंट के तौर पर देखें.
::view-transition
└─ ::view-transition-group(root)
└─ ::view-transition-image-pair(root)
├─ ::view-transition-old(root) 👈 Screenshot
└─ ::view-transition-new(root) 👈 Live representation
लाइव व्यू की इस सुविधा की मदद से, इस तरह के डेमो काम करते हैं: व्यू ट्रांज़िशन के दौरान, नए स्नैपशॉट से लिया गया वीडियो चलता रहता है.
इसके लिए इस्तेमाल किए गए लॉजिक और सीएसएस के बारे में हमारे दस्तावेज़ में पूरी जानकारी दी गई है.
गलतफ़हमी 2: एक से ज़्यादा एलिमेंट कैप्चर करने पर, एक से ज़्यादा व्यू ट्रांज़िशन चलने लगते हैं
एक से ज़्यादा एलिमेंट कैप्चर करने पर, स्नैपशॉट लेने की प्रोसेस में सभी पुरानी और नई स्थितियां कैप्चर हो जाएंगी. :root एलिमेंट के साथ-साथ .box को कैप्चर करने पर, आपको यह स्यूडो ट्री दिखता है:
::view-transition
└─ ::view-transition-group(root)
| └─ ::view-transition-image-pair(root)
| ├─ ::view-transition-old(root)
| └─ ::view-transition-new(root)
└─ ::view-transition-group(box)
└─ ::view-transition-image-pair(box)
├─ ::view-transition-old(box)
└─ ::view-transition-new(box)
इस ट्री में कई स्नैपशॉट पेयर होते हैं, लेकिन सिर्फ़ एक व्यू ट्रांज़िशन चलाया जाता है.
फ़िलहाल, Chrome में एक ही समय में हर दस्तावेज़ के लिए एक व्यू ट्रांज़िशन चलाया जा सकता है. नया व्यू ट्रांज़िशन शुरू करने के लिए, इस डेमो में तेज़ी से क्लिक करें. आपको दिखेगा कि जब कोई नया ट्रांज़िशन शुरू होगा, तो चल रहा ट्रांज़िशन आखिर तक स्किप हो जाएगा.
तीसरा गलतफ़हमी: ब्राउज़र के साथ काम करने की वजह से, व्यू ट्रांज़िशन लागू नहीं किए जा सकते
कई डेवलपर को इस बात की चिंता है कि वे व्यू ट्रांज़िशन लागू नहीं कर पाएंगे, क्योंकि यह सुविधा सिर्फ़ Chrome पर काम करती है. अच्छी बात यह है कि Safari इस पर काम कर रहा है और इसे Safari 18 के अगले रिलीज़ में शामिल करेगा.
हालांकि, ब्राउज़र के साथ काम न करने की वजह से, व्यू ट्रांज़िशन की सुविधा को आज ही लागू न करें. व्यू ट्रांज़िशन, प्रगतिशील बेहतर बनाने के लिए सबसे सही कॉन्टेंट हैं. ओरिजनल दस्तावेज़ में, इस तरीके को कोड में जोड़ने का तरीका बताया गया है.
function handleClick(e) {
// Fallback for browsers that don't support this API:
if (!document.startViewTransition) {
updateTheDOMSomehow();
return;
}
// With a View Transition:
document.startViewTransition(() => updateTheDOMSomehow());
}
अगर आपके ब्राउज़र पर एक ही दस्तावेज़ के व्यू ट्रांज़िशन की सुविधा काम करती है, तो आपको बेहतर और ऐनिमेशन वाला वर्शन दिखेगा. अगर आपके ब्राउज़र में यह सुविधा नहीं है, तो आपको मौजूदा अनुभव मिलेगा. समय के साथ, ज़्यादा से ज़्यादा ब्राउज़र में व्यू ट्रांज़िशन की सुविधा काम करने लगेगी. इससे ज़्यादा से ज़्यादा उपयोगकर्ताओं को बेहतर वर्शन का अनुभव अपने-आप मिलेगा.
यही बात अलग-अलग दस्तावेज़ों के व्यू के ट्रांज़िशन पर भी लागू होती है. जो ब्राउज़र इन पर काम नहीं करते वे स्टाइलशीट को पार्स करते समय, सीएसएस ऑप्ट-इन को अनदेखा कर देंगे.
इस केस स्टडी में बताया गया है कि इस तरीके को ई-कॉमर्स में सफलतापूर्वक लागू किया गया था
गलतफ़हमी #4: व्यू ट्रांज़िशन, इंक्रीमेंटल रेंडरिंग को रोकते हैं
ऐसे दावे हैं कि व्यू ट्रांज़िशन की वजह से, इंक्रीमेंटल रेंडरिंग की सुविधा काम नहीं करती. यह सही नहीं है: क्रॉस-दस्तावेज़ व्यू ट्रांज़िशन को वेब के इस बुनियादी पहलू को न तोड़ने के लिए बनाया गया था और न ही इसे बदलने के लिए.
ब्राउज़र किसी पेज को तब रेंडर करना शुरू करते हैं, जब उनके पास "ज़रूरत के मुताबिक" कॉन्टेंट हो. ज़्यादातर ब्राउज़र में, <head> में सभी स्टाइलशीट लोड करने, <head> में रेंडर को ब्लॉक करने वाले सभी JavaScript को पार्स करने, और ज़रूरत के मुताबिक मार्कअप लोड करने के बाद, यह समय दिखता है. अलग-अलग दस्तावेज़ों के व्यू के बीच ट्रांज़िशन करने से, इस पर कोई असर नहीं पड़ता: साइट का पहला एलिमेंट लोड होने में लगने वाला समय मेट्रिक के लिए ज़रूरी कॉन्टेंट में कोई बदलाव नहीं होता. पहले रेंडर के बाद, ब्राउज़र नए कॉन्टेंट को धीरे-धीरे रेंडर कर सकता है और करेगा.
आपके पास तब तक रेंडरिंग को ब्लॉक करने का विकल्प होता है, जब तक डीओएम में कोई खास एलिमेंट मौजूद होता है. यह उन स्थितियों में सुविधाजनक होता है जहां आपको यह पक्का करना हो कि व्यू ट्रांज़िशन में शामिल एलिमेंट, नए पेज पर मौजूद हैं.
ऐसा करने के लिए, इस लिंक टैग का इस्तेमाल करें:
<link rel="expect" blocking="render" href="#elementId">
इससे, ब्राउज़र के उन हेयुरिस्टिक्स को बदल दिया जाता है जिनका इस्तेमाल यह तय करने के लिए किया जाता है कि पहला रेंडर कब किया जाए: पहला रेंडर तब तक देर से होता है, जब तक कि तय किया गया एलिमेंट डीओएम ट्री में मौजूद न हो.
मैन्युअल तरीके से ब्लॉक करने की सुविधा में, सुरक्षा के कुछ उपाय पहले से मौजूद होते हैं. उदाहरण के लिए, जब क्लोज़िंग </html> टैग दिखता है, लेकिन ब्लॉक करने वाला एलिमेंट नहीं दिखता है, तो रेंडरिंग को ब्लॉक नहीं किया जाएगा. इसके अलावा, अपना टाइम आउट लॉजिक भी जोड़ा जा सकता है, जो किसी भी समय ब्लॉकिंग एट्रिब्यूट को हटा देता है.
इससे पता चलता है कि रेंडर ब्लॉकिंग का इस्तेमाल सावधानी से किया जाना चाहिए. रेंडरिंग को ब्लॉक करने के असर का आकलन, हर मामले के हिसाब से करना होगा. डिफ़ॉल्ट रूप से, blocking=render का इस्तेमाल तब तक न करें, जब तक कि आपके पास परफ़ॉर्मेंस मेट्रिक पर पड़ने वाले असर को मेज़र करने के साथ-साथ, यह भी पता लगाने का विकल्प न हो कि इससे आपके उपयोगकर्ताओं पर क्या असर पड़ेगा.
पांचवां गलतफ़हमी: स्नैपशॉट लेने की प्रोसेस धीमी या महंगी है
जब View Transition API नया व्यू तैयार करता है और उसका स्नैपशॉट लेता है, तब उपयोगकर्ता को पुराना व्यू दिखता रहता है. इस वजह से, उपयोगकर्ता को व्यू ट्रांज़िशन के बिना पुराना पेज थोड़ी देर तक दिखता है. हालांकि, यह देरी मामूली होती है और असल में सिर्फ़ कुछ फ़्रेम की होती है. उदाहरण के लिए, Chrome में pageswap का असर, ज़्यादा से ज़्यादा दो पुराने फ़्रेम पर पड़ता है: एक लॉजिक को लागू करने के लिए और एक अतिरिक्त फ़्रेम, ताकि यह पक्का किया जा सके कि स्नैपशॉट को कंपोज और कैश मेमोरी में सेव किया गया है.
इसके अलावा, स्नैपशॉट का डेटा सीधे कंपोजिटर से लिया जाता है. इसलिए, स्नैपशॉट का डेटा पाने के लिए, अतिरिक्त लेआउट या फिर से रंग भरने की ज़रूरत नहीं होती.
बोनस के तौर पर गलतफ़हमी: यह व्यू ट्रांज़िशन एपीआई है
व्यू ट्रांज़िशन के बारे में बात करते समय, लोग अक्सर "व्यू ट्रांज़िशन एपीआई" का रेफ़रंस देते हैं. यह गलत है. इस एपीआई को "व्यू ट्रांज़िशन एपीआई" कहा जाता है. ध्यान दें कि "ट्रांज़िशन" एकवचन है.
गलतफ़हमी कुछ लेखों की वजह से पैदा हुई है. इनमें एक समय पर, डीसीसी के बारे में हमारे दस्तावेज़ भी शामिल हैं. इनमें गलत शब्द का इस्तेमाल किया गया है.
सही नाम याद रखने का तरीका यह है कि एक या उससे ज़्यादा व्यू ट्रांज़िशन बनाने के लिए, एक व्यू ट्रांज़िशन एपीआई का इस्तेमाल करें.