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

Bramus

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">

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

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

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

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

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

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

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

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

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

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