ב-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(), כלומר אי אפשר להפעיל אותו בכל אירועי הניווט. אי אפשר ליירט ניווטים בין מקורות שונים, וגם לא טרaversals בין מסמכים שונים. הפעולה הזו תוביל להשלכת 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 הזה מכיל מידע רב במיוחד למפתחי אתרים.