يقدِّم Chrome 105 طريقتين جديدتين في NavigateEvent لواجهة واجهة برمجة تطبيقات التنقل (التي تم طرحها في العام 102) لتحسين الطرق التي ثبتت مشكلاتها عمليًا. intercept()، الذي يتيح للمطوّرين التحكّم في الحالة بعد التنقّل، سيحلّ محلّ transitionWhile() الذي واجه صعوبة في استخدامه تؤدي الطريقة scroll() التي تؤدي إلى الانتقال إلى علامة ارتساء محدّدة في عنوان URL إلى استبدال restoreScroll()، وهي لا تعمل مع جميع أنواع التنقّل.
في هذه المقالة، سأشرح المشاكل في كليهما وكيف تعمل الطرق الجديدة على حلّها.
NavigateEvent.transitionWhile()
تمنع الطريقة NavigateEvent.trasitionWhile()، التي تم تقديمها مع واجهة برمجة التطبيقات للتنقل في الإصدار 102 من Chrome، التنقل خلال عمليات الانتقال من جهة العميل في تطبيقات الصفحة الواحدة. الوسيطة الأولى هي وعد يشير إلى المتصفح وأجزاء أخرى من تطبيق الويب بأنه تم الانتهاء من ذلك.
عمل هذا بشكل ضعيف في الواقع. ضع في اعتبارك نمط البرمجة الشائع هذا:
event.transitionWhile((async () => {
doSyncStuff();
await doAsyncStuff();
})());
وهذا الرمز مكافئ عمليًا للرمز البرمجي الوارد أدناه. يؤدي ذلك إلى تنفيذ جزء من عملية التنقّل قبل أن تدرك واجهة برمجة التطبيقات أنّ المطوّر يهدف إلى اعتراض عملية التنقّل.
doSyncStuff();
event.transitionWhile((async () => {
await doAsyncStuff();
})());
وأحد الأمثلة على ذلك الذي يمكن أن يؤدي إلى إفساد التطبيق هو منطق استعادة التمرير حيث يلتقط مواضع التمرير بعد تغيير DOM، بدلاً من قبل.
التغييرات التي أُجريت
لاستبدال transitionWhile()، تقدّم المواصفات الحالية NavigateEvent.intercept(). تستخدم الطريقة الجديدة معالِجًا بالإضافة إلى السمتَين focusReset وscrollRestoration المتوافقتَين في transitionWhile(). يتم تشغيل المعالِج الجديد دائمًا بعد تنفيذ عملية التنقّل، ويتم تسجيل مواضع التمرير، مثل تجنُّب المشاكل المتعلّقة بـ transitionWhile().
لا تزال طريقة transitionWhile() متاحة، ولكن تم إيقافها نهائيًا وستتم إزالتها في الإصدار 108 من Chrome.
استخدام الدالة مَعلمة()
يخضع NavigateEvent.intercept() نفس القيود المفروضة على transitionWhile()، كما هو الحال في جميع أحداث التنقّل. ولا يمكن اعتراض عمليات الانتقال من نطاقات أخرى، ولا يمكن أيضًا إجراء عمليات اجتياز عدّة مستندات. سيؤدي ذلك إلى عرض DOMException من النوع "SecurityError".
لاستخدام intercept()، ما عليك سوى ضبط المعالج المخصّص عند طلبه.
navigation.addEventListener("navigate", event => {
event.intercept({
async handler() {
doSyncStuff();
await doAsyncStuff();
}
});
});
NavigateEvent.scroll()
يتعامل المتصفِّح بالكامل مع عمليات التنقّل، مثل الانتقال من أعلى الصفحة إلى علامة ارتساء (وهذا يعني أنّها تنتقل من /a إلى /a#id) بشكلٍ كامل حتى في تطبيق من صفحة واحدة. أمّا الانتقال إلى شريط ارتساء على "صفحة" أخرى (من /a إلى /b#id)، وهو أمر بسيط بالنسبة إلى التطبيقات المتعددة الصفحات، فيكون أكثر تعقيدًا بالنسبة إلى التطبيقات التي تتضمّن صفحة واحدة. ويجب أن يعترض التطبيق عملية التنقّل إلى /b#id باستخدام NavigateEvent.transitionWhile()، ثم طلب NavigateEvent.restoreScroll() لعرض علامة الارتساء. كما هو موضح أعلاه، يصعب حاليًا إجراء ذلك.
التغييرات التي أُجريت
في تطبيقات الصفحة الواحدة، يمكنك الآن التحكّم في ما إذا كان المتصفّح سيعالج التمرير إلى علامة ارتساء أو ما إذا كان الرمز سيعالجها.
استخدام Scroll()
سيحاول المتصفّح تلقائيًا معالجة الانتقال للأعلى أو للأسفل، بعد أن تتم معالجة الاعتراض. إذا أردت معالجة عملية التنقّل بنفسك، اضبط scroll على "manual"، ثم اطلب NavigateEvent.scroll() عندما يحاول المتصفّح ضبط موضع الانتقال.
navigation.addEventListener("manual", event => {
scroll: "manual",
event.intercept({
async handler() {
doSyncStuff();
// Handle scrolling earlier than by default:
event.scroll();
await doAsyncStuff();
}
});
});
لا تزال طريقة restoreScroll() متاحة، ولكن تم إيقافها نهائيًا وستتم إزالتها في الإصدار 108 من Chrome.
الخلاصة
نأمل أن نعدّل مقالتنا عن واجهة برمجة تطبيقات التنقّل في وقت قريب. في الوقت الحالي، تتضمن مواصفات واجهة برمجة التطبيقات هذه الكثير من المعلومات المخصصة لمطوّري برامج الويب.