מפתחים שמשתמשים ב-service workers וב-Cache Storage API צריכים לשים לב לשני שינויים קטנים שיושקו ב-Chrome 71. שני השינויים האלה מאפשרים להטמיע את Chrome בהתאם למפרטים ולדפדפנים אחרים.
איסור על קריאה אסינכררונית ל-importScripts()
importScripts()
מורה לסקריפט הראשי של ה-service worker להשהות את הביצוע הנוכחי שלו, להוריד קוד נוסף מכתובת URL מסוימת ולהריץ אותו עד לסיום בהיקף הגלובלי הנוכחי. בסיום התהליך, סקריפט ה-service worker הראשי ממשיך את הביצוע. importScripts()
שימושי כשרוצים לחלק את הסקריפט של ה-Service Worker לחלקים קטנים יותר למטרות ארגוניות, או להשתמש בקוד של צד שלישי כדי להוסיף פונקציונליות ל-Service Worker.
דפדפנים מנסים לצמצם את תופעות הביצועים האפשריות של 'הורדה והפעלה של קוד סינכרוני' על ידי שמירה אוטומטית במטמון של כל מה שנמשך דרך importScripts()
. כלומר, אחרי ההורדה הראשונית, הפעלת הקוד המיובא כרוכה בתקורה קטנה מאוד.
עם זאת, כדי שהדבר יפעל, הדפדפן צריך לדעת שלא יהיה קוד "לא צפוי" שייובא ל-service worker אחרי ההתקנה הראשונית.
בהתאם למפרט של שירות העבודה, קריאה ל-importScripts()
אמורה לפעול רק במהלך ההרצה הסינכרונית של הסקריפט של שירות העבודה ברמה העליונה, או במקרה הצורך, באופן אסינכרוני בתוך הטיפולן של install
.
לפני Chrome 71, אפשר היה להפעיל את importScripts()
באופן אסינכרוני מחוץ למטפל install
. החל מ-Chrome 71, הקריאות האלה יגרמו להשלכת חריגה בסביבת זמן הריצה (אלא אם אותה כתובת URL ייבאה בעבר בטיפול של install
), בהתאם להתנהגות בדפדפנים אחרים.
במקום קוד כמו זה:
// This only works in Chrome 70 and below.
self.addEventListener('fetch', event => {
importScripts('my-fetch-logic.js');
event.respondWith(self.customFetchLogic(event));
});
קוד ה-service worker אמור להיראות כך:
// Move the importScripts() to the top-level scope.
// (Alternatively, import the same URL in the install handler.)
importScripts('my-fetch-logic.js');
self.addEventListener('fetch', event => {
event.respondWith(self.customFetchLogic(event));
});
הוצאה משימוש של כתובות URL חוזרות שמועברות לפונקציה cache.addAll()
אם אתם משתמשים ב-Cache Storage API לצד קובץ שירות (service worker), יש שינוי קטן נוסף ב-Chrome 71 שמתאים למפרט הרלוונטי. כשאותה כתובת URL מועברת כמה פעמים לקריאה אחת ל-cache.addAll()
, לפי המפרט ההבטחה שמוחזרת מהקריאה צריכה להידחות.
לפני Chrome 71, הבעיה הזו לא זוהתה וכתובות ה-URL הכפולות לא נלקחו בחשבון.
הרישום ביומן הוא הכנה לקראת Chrome 72, שבו במקום רק אזהרה ביומן, כתובות URL כפולות יובילו לדחייה על ידי cache.addAll()
. אם אתם קוראים ל-cache.addAll()
כחלק משרשור הבטחה (promise) שמוענק ל-InstallEvent.waitUntil()
, כפי שנהוג, הדחייה הזו עלולה לגרום לכך שקובץ השירות לא יותקן.
אלה הבעיות האפשריות:
const urlsToCache = [
'/index.html',
'/main.css',
'/app.js',
'/index.html', // Oops! This is listed twice and should be removed.
];
self.addEventListener('install', event => {
event.waitUntil(
caches.open('my-cache').then(cache => cache.addAll(urlsToCache))
);
});
ההגבלה הזו חלה רק על כתובות ה-URL בפועל שמועברות אל cache.addAll()
, והטמעת מטמון של שתי תגובות מקבילות עם כתובות URL שונות – כמו '/'
ו-'/index.html'
– לא תגרום לדחייה.
בדיקה מקיפה של הטמעת ה-service worker
בשלב הזה, קובצי שירות (service worker) מוטמעים באופן נרחב בכל הדפדפנים המובילים לטווח ארוך. אם אתם בודקים באופן קבוע את Progressive Web App באמצעות מספר דפדפנים, או אם יש לכם מספר גדול של משתמשים שלא משתמשים ב-Chrome, סביר להניח שכבר זיהיתם את חוסר העקביות ועדכנתם את הקוד. עם זאת, אם לא שמתם לב להתנהגות הזו בדפדפנים אחרים, רצינו להודיע לכם על השינוי לפני שנשנה את התנהגות Chrome.