ב-Chrome 105 נוספו שתי שיטות חדשות ב-NavigateEvent של Navigation 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(). השיטה החדשה מקבלת טיפולן בנוסף למאפיינים focusReset ו-scrollRestoration שנתמכים על ידי transitionWhile(). הטיפול החדש תמיד פועל אחרי שהניווט מחויב, ודברים כמו מיקומי גלילה מתועדים, וכך נמנעות הבעיות שקשורות ל-transitionWhile().
השיטה transitionWhile() עדיין זמינה, אבל היא הוצאה משימוש ותוסר בגרסת Chrome 108.
שימוש ב-intercept()
על 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() עדיין זמינה, אבל היא הוצאה משימוש ותוסר בגרסת Chrome 108.
סיכום
אנחנו מקווים לעדכן בקרוב את המאמר שלנו בנושא Navigation API. בינתיים, המפרט של ה-API הזה מכיל מידע רב במיוחד למפתחי אתרים.