المفاهيم الخاطئة حول انتقالات المشاهدات

Bramus

تُعدّ واجهة برمجة التطبيقات View Transition API عنصرًا أساسيًا في تطوير الويب. سواء كان موقعك الإلكتروني يتضمّن صفحة واحدة أو صفحات متعددة، تتيح لك واجهة برمجة التطبيقات هذه إنشاء انتقالات سلسة بين طرق العرض، ما يؤدي إلى توفير تجارب شبيهة بالتطبيقات الأصلية تجذب المستخدمين. تتوفّر هذه الميزة حاليًا في Chrome، وستتوفّر قريبًا في Safari أيضًا.

مع بدء المزيد من المستخدمين في الاطّلاع على View Transition API، حان الوقت لتوضيح بعض المفاهيم الخاطئة.

الاعتقاد الخاطئ 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

بفضل هذا المظهر المباشر، تعمل العروض التوضيحية مثل هذه: يستمر تشغيل الفيديو المستمَد من اللقطة الجديدة أثناء انتقال العرض.

فيديو مشغّل يشارك في عملية انتقال عرض العرض التجريبي البسيط المصدر:

يمكنك الاطّلاع على المستندات لمعرفة التفاصيل حول المنطق ولغة CSS المستخدَمة لتنفيذ ذلك.

الاعتقاد الخاطئ الثاني: يؤدي التقاط أكثر من عنصر واحد إلى تشغيل عمليات انتقال متعددة للعرض

عند التقاط عناصر متعددة، ستلتقط عملية التقاط اللقطات جميع الحالات القديمة والجديدة. عند تسجيل .box بالإضافة إلى عنصر :root، ستحصل على هذه الشجرة الزائفة:

::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 حاليًا على تشغيل انتقال عرض واحد لكل مستند في الوقت نفسه. جرِّب النقر بسرعة في هذا العرض التجريبي لبدء انتقال عرض جديد. ستلاحظ أنّ الانتقال الجاري ينتقل إلى النهاية عند بدء انتقال جديد.

ملاحظة: في المستقبل، باستخدام الانتقالات على مستوى العنصر، ستتمكّن من تنفيذ انتقال على شجرة فرعية من DOM، وسيكون من الممكن أيضًا إجراء انتقالات متزامنة في مستند واحد، ما دامت لا تشارك عناصر تم التقاط لقطات لها.

الاعتقاد الخاطئ 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());
}

إذا كان المتصفّح يتيح عمليات النقل بين طرق عرض المستند نفسه، ستظهر لك النسخة المفصّلة والمتحرّكة. إذا لم يكن المتصفّح متوافقًا، ستحصل على التجربة الحالية. وبمرور الوقت، مع توفّر ميزة انتقالات العرض في المزيد من المتصفحات، سيحصل المزيد من المستخدمين على هذه التجربة المحسّنة تلقائيًا.

وينطبق الأمر نفسه على عمليات النقل بين طرق العرض في المستندات المختلفة. أما المتصفحات التي لا تتوافق مع هذه العلامات، فستتجاهل تفعيل CSS عند تحليل أوراق الأنماط.

تم تنفيذ هذا النهج بنجاح في مجال التجارة الإلكترونية، كما هو موضّح بالتفصيل في دراسة الحالة هذه.

ملاحظة: يجب أيضًا مراعاة الإعدادات المفضّلة للمستخدم في ما يتعلّق بتقليل الحركة. ويمكن إجراء ذلك في JavaScript أو في CSS من خلال تضمين كل هذه الأسماء أو الصور المتحركة في الشرط @media (prefers-reduced-motion: no-reduce). إذا لم يتمّ التقاط أيّ عناصر أو لم تكن هناك أيّ رسوم متحركة لتشغيلها، يبدّل انتقال العرض نموذج DOM القديم بنموذج DOM الجديد بدون حدوث أيّ رسوم متحركة. مزيد من المعلومات حول الصور المتحركة وتسهيل الاستخدام

الاعتقاد الخاطئ 4: تؤدي عمليات النقل إلى إيقاف العرض المتزايد

هناك مطالبات بأنّ عمليات انتقال العرض تؤدي إلى إيقاف العرض المتزايد. هذا غير صحيح: تم تحديد عمليات النقل بين طرق العرض في المستندات المختلفة كي لا تؤدي إلى إيقاف هذا الجانب الأساسي من الويب.

تبدأ المتصفّحات بعرض الصفحة عندما يكون لديها محتوى "كافٍ". يحدث ذلك في معظم المتصفحات بعد تحميل جميع ملفات الأنماط في <head> وتحليل كل JavaScript الذي يعرقل عرض المحتوى في <head> وتحميل علامات كافية. ولا تؤدي عمليات النقل بين طرق العرض في المستندات المختلفة إلى تغيير ذلك: لا يتم تغيير المحتوى المطلوب لسرعة عرض أوّل محتوى مرئي. بعد هذا العرض الأول، يمكن للمتصفّح عرض المحتوى الذي تم استلامه حديثًا بشكل تدريجي.

يمكنك اختيار حظر العرض إلى أن يظهر عنصر معيّن في DOM. يكون ذلك مفيدًا في الحالات التي تريد فيها التأكّد من أنّ العناصر المشارِكة في انتقال العرض متوفّرة في الصفحة الجديدة.

ولإجراء ذلك، استخدِم علامة الرابط هذه:

<link rel="expect" blocking="render" href="#elementId">

ويؤدي ذلك إلى إلغاء الأساليب الاستقرائية للمتصفّح المستخدَمة لتحديد وقت إجراء العرض الأول: يتم تأخير العرض الأول إلى أن يظهر العنصر المحدّد في شجرة نموذج DOM.

يتضمّن الحظر اليدوي بعض الإجراءات الوقائية المضمّنة. على سبيل المثال، عندما تظهر علامة الإغلاق </html> ولكن لا يظهر العنصر الذي يحظر العرض، لن يتم حظر العرض بعد ذلك. بالإضافة إلى ذلك، يمكنك إضافة منطق وقت الاستراحة الخاص بك الذي يزيل سمة الحظر في أي وقت.

من الواضح أنّه يجب استخدام حظر العرض بحذر. يجب تقييم تأثير حظر العرض على أساس كل حالة على حدة. تجنَّب استخدام blocking=render تلقائيًا ما لم تتمكّن من قياس تأثيره في المستخدمين وتقييمه بشكل نشط، وذلك من خلال قياس تأثيره في مقاييس الأداء.

الاعتقاد الخاطئ 5: عملية إنشاء النُسخ الاحتياطية بطيئة أو باهظة التكلفة

بينما تحضّر View Transition API طريقة العرض الجديدة وتحصل على لقطات لها، تظل طريقة العرض القديمة مرئية للمستخدم. ولهذا السبب، يتمكّن المستخدم من الاطّلاع على الصفحة القديمة لفترة أطول قليلاً مقارنةً بما لو لم تكن هناك عمليات انتقال بين طرق العرض. ومع ذلك، هذا التأخير لا يُذكر، فهو يُمثّل بضع لقطات فقط في الواقع. في Chrome، يتسبب pageswap مثلاً في ظهور إطارَين قديمَين كحد أقصى: إطار لتنفيذ المنطق وإطار إضافي لضمان دمج اللقطات وتخزينها مؤقتًا.

بالإضافة إلى ذلك، يتم الحصول على بيانات اللقطات مباشرةً من أداة الدمج، لذا لا يلزم تنفيذ خطوات إضافية لإعادة التصميم أو إعادة الطلاء من أجل الحصول على بيانات اللقطة.

مفهوم خاطئ إضافي: واجهة برمجة التطبيقات هي View Transitions API

عند الحديث عن انتقالات العرض، يشير المستخدمون غالبًا إلى واجهة برمجة التطبيقات View Transitions API. هذا غير صحيح. تُعرف واجهة برمجة التطبيقات باسم "View Transition API"، مع ملاحظة أنّ "الانتقال" مفرد.

يرجع هذا المفهوم الخاطئ إلى استخدام بعض المقالات للمصطلح غير الصحيح، بما في ذلك مستنداتنا الخاصة حول DCC.

إنّ الطريقة لتذكر الاسم الصحيح هي استخدام واجهة برمجة التطبيقات View Transition API (واحدة) لإنشاء انتقالات عرض (واحدة أو أكثر).