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