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

واجهة 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 المستخدَمين في ذلك.

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

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

المفهوم الخاطئ 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) عند تحليل أوراق الأنماط.

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

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

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

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

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

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

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

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

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

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

الاعتقاد الخاطئ 5: عملية التصوير بطيئة أو مكلفة

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

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

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

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

ينبع الاعتقاد الخاطئ من بعض المقالات، بما في ذلك في مرحلة معيّنة مستنداتنا الخاصة بـ DCC، التي تستخدم المصطلح غير الصحيح.

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