בגרסה 105 של Chrome השקנו שתי שיטות חדשות ב-NavigateEvent של ממשק ה-API לניווט (הושק ב-102) כדי לשפר שיטות שהוכחו כבעייתיות בפועל. intercept(), שמאפשר למפתחים לשלוט במצב במהלך הניווט, מחליף את transitionWhile(), שקשה להשתמש בו. השיטה scroll(), שגוללת לעוגן שצוין בכתובת ה-URL, מחליפה את restoreScroll(), שלא פועלת בכל סוגי הניווט.
במאמר הזה אסביר את הבעיות בשני הסוגים ואת האופן שבו השיטות החדשות פותרות אותן.
NavigateEvent.transitionWhile()
השיטה NavigateEvent.trasitionWhile(), שהושקה עם Navigation API ב-Chrome 102, מיירטת את הניווט לצורך מעברים בצד הלקוח באפליקציות בדף יחיד. הארגומנט הראשון שלו הוא הבטחה שמסמן לדפדפן ולחלקים אחרים באפליקציית האינטרנט שהפעולה הסתיימה.
בפועל, זה לא עבד טוב. חשוב לזכור את דפוס התכנות הנפוץ הבא:
event.transitionWhile((async () => {
doSyncStuff();
await doAsyncStuff();
})());
הפונקציה הזו מקבילה לקוד שבהמשך. היא גורמת לחלק מסוים מהניווט לפעול לפני שה-API מודע לכך שהמפתח מתכוונים ליירט את הניווט.
doSyncStuff();
event.transitionWhile((async () => {
await doAsyncStuff();
})());
דוגמה אחת למצב שבו אפליקציה יכולה להקשות על אפליקציה היא בלוגיקת שחזור הגלילה שבה היא מתעדת מיקומי גלילה אחרי שינוי ה-DOM, ולא לפני כן.
מה השתנה
כדי להחליף את transitionWhile(), המפרט הנוכחי מציג את NavigateEvent.intercept(). השיטה החדשה מקבלת handler בנוסף למאפיינים focusReset ו-scrollRestoration שנתמכים ב-transitionWhile(). ה-handler החדש תמיד רץ אחרי שהניווט נשמר, ודברים כמו מיקומי גלילה תועדו כדי למנוע בעיות ב-transitionWhile().
השיטה transitionWhile() עדיין זמינה, אבל היא הוצאה משימוש ותוסר בגרסה 108 של Chrome.
שימוש ב-break()
על NavigateEvent.intercept() יש אותן הגבלות כמו transitionWhile(), כמו שלא ניתן להפעיל אותו בכל אירועי הניווט. לא ניתן ליירט ניווטים בין מקורות, וגם לא מעברים בין מסמכים. הפעולה הזו תגרור DOMException מסוג "SecurityError".
כדי להשתמש ב-intercept(), פשוט מעבירים את ה-handler המותאם אישית בזמן הקריאה אליו.
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 לערך "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.
סיכום
אנחנו מקווים לעדכן בקרוב את המאמר שלנו על Navigation API. בינתיים, המפרט של ה-API הזה כולל הרבה מידע שמיועד למפתחי אתרים.