व्यू ट्रांज़िशन से जुड़ी गलतफ़हमियां

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

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

गलतफ़हमी 1: View Transit 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 एक समय में हर दस्तावेज़ के लिए एक व्यू ट्रांज़िशन चला सकता है. नया व्यू ट्रांज़िशन शुरू करने के लिए, इस डेमो में तेज़ी से क्लिक करने की कोशिश करें. नया ट्रांज़िशन शुरू होने पर, आपको दिखेगा कि ट्रांज़िशन की प्रोसेस खत्म होने वाली है.

गलतफ़हमी 3: ब्राउज़र के साथ काम करने की वजह से, व्यू ट्रांज़िशन लागू नहीं किए जा सकते

कई डेवलपर को लगता है कि वे व्यू ट्रांज़िशन लागू नहीं कर सकते, क्योंकि यह सिर्फ़ 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">

यह ब्राउज़र के अनुभव को ओवरराइड कर देता है, जिसकी मदद से यह तय किया जाता है कि अपना पहला रेंडर कब करना है: पहला रेंडर तब तक देर से होता है, जब तक कि बताया गया एलिमेंट DOM ट्री में मौजूद नहीं होता.

मैन्युअल तरीके से ब्लॉक करने की इस प्रोसेस में, सुरक्षा के कुछ उपाय पहले से मौजूद हैं. उदाहरण के लिए, अगर </html> टैग दिखता है, लेकिन ब्लॉक करने वाला एलिमेंट नहीं दिखता, तो रेंडरिंग को ब्लॉक नहीं किया जाएगा. इसके अलावा, टाइम आउट का लॉजिक भी जोड़ा जा सकता है. इससे किसी भी समय ब्लॉक करने वाला एट्रिब्यूट हट जाता है.

यह साफ़ तौर पर पता चलता है कि रेंडर ब्लॉक करने के टूल का इस्तेमाल सावधानी से किया जाना चाहिए. रेंडरिंग को ब्लॉक करने से होने वाले असर का आकलन, अलग-अलग पहलुओं को ध्यान में रखकर किया जाना चाहिए. डिफ़ॉल्ट रूप से, blocking=render का इस्तेमाल तब तक न करें, जब तक आप परफ़ॉर्मेंस मेट्रिक पर पड़ने वाले असर को मेज़र करके, उपयोगकर्ताओं पर पड़ने वाले असर को सही तरीके से मेज़र और नाप सकें.

गलतफ़हमी 5: स्नैपशॉट लेने की प्रोसेस धीमी या महंगी है

जब तक व्यू ट्रांज़िशन एपीआई नया व्यू तैयार करता है और उसके स्नैपशॉट हासिल करता है, तब तक पुराना व्यू उपयोगकर्ता को दिखता रहता है. इस वजह से, उपयोगकर्ता को पुराना पेज, बिना व्यू ट्रांज़िशन वाले पेज की तुलना में थोड़ा लंबा दिखने लगता है. हालांकि, असल में सिर्फ़ कुछ फ़्रेम में यह देरी न के बराबर होती है. उदाहरण के लिए, Chrome में pageswap का असर ज़्यादा से ज़्यादा दो पुराने फ़्रेम के असर पर पड़ता है: पहला, लॉजिक को लागू करने के लिए और एक अतिरिक्त फ़्रेम, ताकि यह पक्का किया जा सके कि स्नैपशॉट को कंपोज़िट और कैश मेमोरी में सेव किया गया है.

इसके अलावा, स्नैपशॉट का डेटा सीधे कंपोज़िटर से लिया जाता है. इसलिए, स्नैपशॉट का डेटा पाने के लिए, अलग से कोई लेआउट या रीपेंट करने की ज़रूरत नहीं होती.

बोनस ग़लतफ़हमी: यह व्यू ट्रांज़िशन एपीआई है

व्यू ट्रांज़िशन की बात करते समय, लोग अक्सर "View Transits API" देखते हैं. यह गलत है. इस एपीआई को "View Transit API" कहा जाता है. एक शब्द "ट्रांज़िशन" पर ध्यान दें.

यह गलत धारणा कुछ लेखों की वजह से आई है. इनमें किसी गलत शब्द का इस्तेमाल करके, डीसीसी पर बनाए गए हमारे दस्तावेज़ भी शामिल हैं.

सही नाम याद रखने का तरीका यह है कि आप (एक) व्यू ट्रांज़िशन एपीआई का इस्तेमाल (एक या एक से ज़्यादा) व्यू ट्रांज़िशन बनाने के लिए करें.