تُعدّ واجهة برمجة التطبيقات 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">
ويؤدي ذلك إلى إلغاء الأساليب الاستقرائية للمتصفّح المستخدَمة لتحديد وقت إجراء العرض الأول: يتم تأخير العرض الأول إلى أن يظهر العنصر المحدّد في شجرة نموذج DOM.
يتضمّن الحظر اليدوي بعض الإجراءات الوقائية المضمّنة. على سبيل المثال، عندما تظهر علامة الإغلاق </html> ولكن لا يظهر العنصر الذي يحظر العرض، لن يتم حظر العرض بعد ذلك. بالإضافة إلى ذلك، يمكنك إضافة منطق المهلة الخاص بك الذي يزيل سمة الحظر في أي وقت.
من الواضح أنّه يجب استخدام حظر العرض بحذر. يجب تقييم تأثير حظر العرض حسب كل حالة على حدة. تجنَّب استخدام blocking=render تلقائيًا ما لم تتمكّن من قياس تأثيره في المستخدمين وتقييمه بشكل نشط، وذلك من خلال قياس تأثيره في مقاييس الأداء.
الاعتقاد الخاطئ 5: عملية التصوير بطيئة أو مكلفة
بينما تعمل واجهة برمجة التطبيقات View Transition API على إعداد طريقة العرض الجديدة والحصول على اللقطات، يظل العرض القديم مرئيًا للمستخدم. ونتيجةً لذلك، يتمكّن المستخدم من الاطّلاع على الصفحة القديمة لفترة أطول قليلاً مقارنةً بما لو لم تكن هناك عمليات انتقال بين طرق العرض. ومع ذلك، هذا التأخير لا يُذكر، إذ لا يتجاوز بضع لقطات في الواقع. في Chrome، يتسبب الخيار pageswap مثلاً في ظهور إطارَين قديمَين كحد أقصى: إطار لتنفيذ المنطق وإطار إضافي لضمان دمج اللقطات وتخزينها مؤقتًا.
بالإضافة إلى ذلك، يتم الحصول على بيانات اللقطات مباشرةً من أداة الدمج، لذا لا يلزم تنفيذ خطوات إضافية لإعادة التصميم أو إعادة الطلاء من أجل الحصول على بيانات اللقطة.
مفهوم خاطئ إضافي: واجهة برمجة التطبيقات هي View Transitions API
عند الحديث عن انتقالات العرض، يشير الأشخاص غالبًا إلى "واجهة برمجة تطبيقات الانتقالات". هذا غير صحيح. تُعرف واجهة برمجة التطبيقات باسم "View Transition API"، مع ملاحظة أنّ "الانتقال" مفرد.
يرجع هذا المفهوم الخاطئ إلى استخدام بعض المقالات للمصطلح غير الصحيح، بما في ذلك مستنداتنا الخاصة حول DCC.
إنّ الطريقة لتذكر الاسم الصحيح هي استخدام واجهة برمجة التطبيقات View Transition API (واحدة) لإنشاء انتقالات عرض (واحدة أو أكثر).