חלון תיבת עבודה

החבילה workbox-window היא קבוצה של מודולים שאמורים לפעול הקשר window, בתוך דפי האינטרנט שלכם. הם השלמה לתיבת העבודה האחרת חבילות שרצות ב-Service Worker.

התכונות או המטרות העיקריות של workbox-window הם:

ייבוא ושימוש בחלון של תיבת עבודה

נקודת הכניסה הראשית לחבילה workbox-window היא המחלקה Workbox. אפשר לייבא אותו בקוד שלכם מה-CDN שלנו או באמצעות כלי קיבוץ JavaScript של JavaScript.

שימוש ב-CDN שלנו

הדרך הקלה ביותר לייבא את המחלקה Workbox באתר היא מה-CDN שלנו:

<script type="module">
  import {Workbox} from 'https://storage.googleapis.com/workbox-cdn/releases/6.4.1/workbox-window.prod.mjs';

  if ('serviceWorker' in navigator) {
    const wb = new Workbox('/sw.js');

    wb.register();
  }
</script>

שימו לב שהדוגמה הזו משתמשת ב-<script type="module"> ובהצהרה import כדי טעינת הכיתה Workbox. למרות שנראה לכם שצריך לתרגם כדי להפעיל אותו בדפדפנים ישנים, בעצם אין צורך.

כל הדפדפנים המובילים שתומכים ב-Service worker תומכים במודולים מקוריים של JavaScript, כך שזה מושלם ניתן להציג את הקוד הזה בכל דפדפן (דפדפנים ישנים יותר פשוט יתעלמו ממנו).

טעינת תיבת עבודה עם Bundler של JavaScript

אין צורך בכלים בכלל כדי להשתמש ב-workbox-window, אבל תשתית פיתוח כבר כוללת Bundler כמו webpack או נכס-על שפועלים עם יחסי תלות של npm, אפשר להשתמש בהם טעינת workbox-window.

השלב הראשון הוא התקנה workbox-window כתלות באפליקציה:

npm install workbox-window

לאחר מכן, באחד מקובצי ה-JavaScript של האפליקציה, תיבת העבודה import של מתייחס לשם החבילה workbox-window:

import {Workbox} from 'workbox-window';

if ('serviceWorker' in navigator) {
  const wb = new Workbox('/sw.js');

  wb.register();
}

אם ה-bundler תומך בפיצול קוד באמצעות הצהרות ייבוא דינמיות, אפשר גם לטעון באופן מותנה את workbox-window, מה שיכול לצמצם את גודל החבילה הראשית של הדף.

למרות ש-workbox-window הוא די קטן, אין סיבה לכך צריכים להיות טעונים על לוגיקת האפליקציות העיקרית של האתר, בתור Service worker, מעצם טבען, הן מהוות שיפור הדרגתי.

if ('serviceWorker' in navigator) {
  const {Workbox} = await import('workbox-window');

  const wb = new Workbox('/sw.js');
  wb.register();
}

מושגים מתקדמים של קיבוץ

בניגוד לחבילות של Workbox שרצות ב-Service Worker, קובצי ה-build שיש הפניה אליו מ-workbox-window main וגם שדות של module ב- package.json מועברים ל-ES5. כך הם תואמים כלי build - שחלקם לא מאפשרים למפתחים להעביר שום דבר ויחסי התלות שלהם ב-node_module.

אם מערכת ה-build מאפשרת להעביר את יחסי התלות (או אם אין צורך להעביר אף אחד מהקודים), עדיף לייבא את קובץ המקור ולא בחבילה עצמה.

אלה הדרכים השונות שבהן אפשר לייבא את Workbox, יחד עם הסבר מה יחזיר כל אחד מהם:

// Imports a UMD version with ES5 syntax
// (pkg.main: "build/workbox-window.prod.umd.js")
const {Workbox} = require('workbox-window');

// Imports the module version with ES5 syntax
// (pkg.module: "build/workbox-window.prod.es5.mjs")
import {Workbox} from 'workbox-window';

// Imports the module source file with ES2015+ syntax
import {Workbox} from 'workbox-window/Workbox.mjs';

דוגמאות

לאחר הייבוא של הכיתה Workbox, תוכלו להשתמש בה כדי לרשום יוצרים אינטראקציה עם ה-Service Worker. הנה כמה דוגמאות לדרכים שבהן אפשר להשתמש Workbox באפליקציה שלך:

רישום קובץ שירות (service worker) והודעה למשתמש בפעם הראשונה ש-Service Worker פעיל

עובדים רבים של שירותי משתמש באפליקציות אינטרנט כדי לשמור נכסים במטמון כדי שהאפליקציה תפעל במצב אופליין בטעינת הדפים הבאים. במקרים מסוימים כדאי לעדכן למשתמש שעכשיו האפליקציה זמינה במצב אופליין.

const wb = new Workbox('/sw.js');

wb.addEventListener('activated', event => {
  // `event.isUpdate` will be true if another version of the service
  // worker was controlling the page when this version was registered.
  if (!event.isUpdate) {
    console.log('Service worker activated for the first time!');

    // If your service worker is configured to precache assets, those
    // assets should all be available now.
  }
});

// Register the service worker after event listeners have been added.
wb.register();

שליחת הודעה למשתמש אם קובץ שירות (service worker) התקין אבל נתקע וממתין להפעלה

כאשר דף שנשלט על ידי קובץ שירות (service worker) קיים רושם שירות חדש ב-Worker, כברירת מחדל, Service Worker לא יופעל עד שכל הלקוחות שנשלט על ידי קובץ השירות (service worker) הראשוני הוסר במלואו.

זה מקור לבלבול בקרב מפתחים, במיוחד במקרים שבהם טעינה מחדש של הדף הנוכחי לא גורמת להפעלה של Service Worker החדש.

כדי להפחית את הסיכוי לבלבול ולהבהיר מתי מצב זה מתרחש, הכיתה Workbox מספקת אירוע waiting שאפשר להאזין לו:

const wb = new Workbox('/sw.js');

wb.addEventListener('waiting', event => {
  console.log(
    `A new service worker has installed, but it can't activate` +
      `until all tabs running the current version have fully unloaded.`
  );
});

// Register the service worker after event listeners have been added.
wb.register();

הודעה למשתמש על עדכונים במטמון מהחבילה workbox-broadcast-update

חבילת workbox-broadcast-update היא דרך מצוינת להציג תוכן מהמטמון (למשלוח מהיר), וגם יכולת להודיע למשתמש על עדכונים לתוכן זה (באמצעות לא פעיל בזמן אימות מחדש של האסטרטגיה).

כדי לקבל את העדכונים האלה מהחלון, אפשר להאזין לאירועי message של סוג CACHE_UPDATED:

const wb = new Workbox('/sw.js');

wb.addEventListener('message', event => {
  if (event.data.type === 'CACHE_UPDATED') {
    const {updatedURL} = event.data.payload;

    console.log(`A newer version of ${updatedURL} is available!`);
  }
});

// Register the service worker after event listeners have been added.
wb.register();

שולחים ל-Service Worker רשימה של כתובות URL למטמון.

עבור אפליקציות מסוימות, אפשר לדעת אילו נכסים צריכים להיכלל נשמר מראש בזמן ה-build, אבל חלק מהאפליקציות ממלאות דפים שונים לגמרי, על סמך כתובת ה-URL שאליה המשתמש מגיע ראשונה.

לאפליקציות בקטגוריה השנייה, כדאי לשמור במטמון רק את הנכסים. המשתמש הדרוש לדף המסוים שבו הוא ביקר. כשמשתמשים באופרטור חבילת workbox-routing, אתם יכולים ישלח לנתב רשימה של כתובות URL לשמירה במטמון, והוא ישמור את כתובות ה-URL האלה במטמון לפי הכללים שמוגדרים בנתב עצמו.

בדוגמה הזו נשלחת לנתב רשימה של כתובות URL שהדף טעון בכל פעם Service Worker חדש הופעל. מותר לשלוח את כל כתובות ה-URL, כי רק כתובות ה-URL שתואמות למסלול מוגדר ב-Service Worker יישמרו במטמון:

const wb = new Workbox('/sw.js');

wb.addEventListener('activated', event => {
  // Get the current page URL + all resources the page loaded.
  const urlsToCache = [
    location.href,
    ...performance.getEntriesByType('resource').map(r => r.name),
  ];
  // Send that list of URLs to your router in the service worker.
  wb.messageSW({
    type: 'CACHE_URLS',
    payload: {urlsToCache},
  });
});

// Register the service worker after event listeners have been added.
wb.register();

רגעים חשובים במחזור החיים של Service Worker

מחזור החיים של Service Worker הוא מורכב ויכול להיות אתגר להבנה מלאה. חלק מהסיבה לכך כל כך מורכב עד שהוא צריך לטפל בכל מקרי הקצה של כל שימושים אפשריים קובץ שירות (service worker) (למשל רישום של יותר מ-Service Worker אחד, רישום פריטי שירות (service worker) שונים במסגרות שונות, רישום עובדי שירות שמות שונים וכו').

אבל רוב המפתחים שמטמיעים Service Worker לא צריכים לדאוג בכל מקרי הקצה האלה כי השימוש בהם די פשוט. הכי הרבה מפתחים רושמים קובץ Service Worker אחד בלבד בכל טעינת דף, והוא לא משנה את שם ה-Service Worker את הקובץ שהם פורסים בשרת שלהם.

הכיתה Workbox כוללת את התצוגה הפשוטה הזו של מחזור החיים של קובץ שירות (service worker) באמצעות חלוקת כל ההרשמות של עובדי שירות לשתי קטגוריות: קובץ שירות (service worker) רשום ועובד שירות חיצוני:

  • Service Worker רשום: קובץ שירות (service worker) שהתחיל להתקין התוצאה של המופע Workbox שקורא ל-register() או למכונה שכבר פעילה קובץ שירות (service worker) אם הקריאה אל register() לא גרמה לאירוע updatefound ברישום.
  • קובץ שירות (service worker) חיצוני:קובץ שירות (service worker) שהתחיל להתקין בנפרד מהמכונה Workbox שקוראת ל-register(). בדרך כלל מצב זה קורה כאשר למשתמש יש גרסה חדשה של האתר פתוחה בכרטיסייה אחרת. כאשר האירוע נוצר על ידי קובץ שירות (service worker) חיצוני, isExternal של האירוע יוגדר כ-true.

לפניכם פירוט של כל סוגי עובדי השירות האלה רגעים חשובים במחזור החיים של קובץ השירות, יחד עם המלצות למפתחים כיצד לטפל בהן:

בפעם הראשונה ש-Service Worker מותקן

סביר להניח שתרצו לטפל בפעם הראשונה ש-Service Worker מתקין באופן שונה מהטיפול בכל העדכונים העתידיים.

בworkbox-window, אפשר להבחין קודם בין הגרסה של ההתקנה ועדכונים עתידיים על ידי בדיקת המאפיין isUpdate בכל אחד את האירועים הבאים. בהתקנה הראשונה ביותר, isUpdate יהיה false.

const wb = new Workbox('/sw.js');

wb.addEventListener('installed', event => {
  if (!event.isUpdate) {
    // First-installed code goes here...
  }
});

wb.register();
ערך אירוע הפעולה המומלצת
קובץ שירות (service worker) חדש התקין (בפעם הראשונה) installed

בפעם הראשונה ש-Service Worker מתקין, מקובל לשמור מראש את כל הנכסים הנדרשים כדי שהאתר יפעל במצב אופליין. כדאי לשקול שמיידע את המשתמשים שעכשיו האתר שלהם יכול לפעול במצב אופליין.

כמו כן, מאז הפעם הראשונה שבה קובץ שירות (service worker) מתקין, אירועי אחזור יירוטו של טעינת הדף הזו, ייתכן שכדאי גם לשמור במטמון נכסים שכבר נטענו (למרות שאין צורך בכך אם הנכסים כבר נשמרים מראש במטמון). שולחים את בדוגמה שלמעלה ל-service worker, רשימה של כתובות URL לשמירה במטמון מראה איך הזה.
קובץ השירות (service worker) התחיל לשלוט בדף controlling

לאחר ש-Service Worker חדש מותקן ומתחיל לשלוט בדף, כל אירועי האחזור הבאים יעברו דרך ה-Service Worker הזה. אם Service Worker מוסיף לוגיקה מיוחדת לטיפול באירוע אחזור ספציפי, זה השלב שבו אתם יודעים שהלוגיקה תפעל.

לתשומת ליבכם: בפעם הראשונה שמתקינים Service Worker י לא יתחילו לשלוט בדף הנוכחי, אלא אם ה-Service Worker שיחות clients.claim() באירוע ההפעלה שלו. ברירת המחדל היא להמתין עד לטעינת הדף הבאה כדי להתחיל לשלוט.

מבחינת workbox-window, המשמעות היא האירוע controlling נשלח רק במקרים שבהם Service Worker קורא למספר clients.claim(). האירוע הזה לא נשלח אם הדף כבר נשלט לפני ההרשמה.
קובץ השירות (service worker) סיים את ההפעלה activated

כפי שצוין למעלה, בפעם הראשונה שבה קובץ שירות מסיים ייתכן שהפעלתם (או לא) התחילה לשלוט בדף.

לכן, לא מומלץ להאזין לאירוע ההפעלה כדרך לדעת מתי ה-Service Worker שולט בדף. אבל אם אתם מפעילים לוגיקה באירוע הפעיל (ב-Service Worker) צריכים לדעת מתי הלוגיקה הזו הושלמה, האירוע שמופעל יאפשר לכם יודעים את זה.

כשנמצאת גרסה מעודכנת של Service Worker

כאשר קובץ שירות (service worker) חדש מתחיל להתקין אבל כרגע יש גרסה קיימת השולט בדף, המאפיין isUpdate של כל האירועים הבאים להיות true.

האופן שבו אתה מגיב במצב זה שונה בדרך כלל מאופן התגובה כי צריך לנהל את המועד והאופן שבהם המשתמש יקבל את העדכון הזה.

ערך אירוע הפעולה המומלצת
מותקן קובץ שירות (service worker) חדש (עדכון גרסה קודמת) installed

אם זו לא הפעם הראשונה ש-Service Worker מתקין (event.isUpdate === true), המשמעות היא גרסה חדשה יותר של ה-service worker נמצא והתקין (כלומר, גרסה אחרת) מהחשבון ששולט כרגע בדף).

בדרך כלל המשמעות היא שגרסה חדשה יותר של האתר פרוסה השרת שלכם, ויכול להיות שהשמירה במטמון של נכסים חדשים הסתיימה עכשיו.

הערה: חלק מהמפתחים משתמשים באירוע installed כדי לקבל מידע למשתמשים שיש גרסה חדשה של האתר שלהם. אבל בהתאם כשמתקשרים skipWaiting() ב-Service Worker להתקנה, Service Worker עשוי להפוך לפעיל באופן מיידי. אם מומלץ להתקשר למספר skipWaiting(). לאחר מכן מומלץ ליידע את המשתמשים של העדכון לאחר שה-Service Worker החדש הופעל, ואם לא להתקשר אל skipWaiting. עדיף לעדכן אותם יש עדכון בהמתנה באירוע ההמתנה (פרטים נוספים מופיעים בהמשך).
קובץ שירות (service worker) התקין אבל הוא נתקע בשלב ההמתנה waiting

אם הגרסה המעודכנת של ה-Service Worker לא מבצעת קריאה ל- skipWaiting() בזמן ההתקנה, לא תתבצע להפעיל עד שכל הדפים בשליטת ה-Service Worker הפעיל הנוכחי הוסרו. כדאי להודיע למשתמש שיש עדכון זמין ויוחל בביקור הבא שלהם.

אזהרה! מפתחים רבים שולחים בקשות למשתמשים כדי לקבל את העדכון, טען מחדש. אבל במקרים רבים רענון הדף לא יפעיל את העובד המותקן. אם משתמש מרענן את הדף וה-Service Worker עדיין ממתין, האירוע waiting יופעל שוב המאפיין event.wasWaitingBeforeRegister יתמלא. הערה: אנחנו מתכננים לשפר את החוויה הזו בגרסה עתידית. מעקב אחר בעיה מס' 1848 לקבלת עדכונים.

אפשרות אחרת היא לשאול את המשתמש אם הוא רוצה או להמשיך להמתין. אם בוחרים לקבל את העדכון, אפשר להשתמש ב-postMessage() כדי להורות ל-Service Worker לרוץ skipWaiting(). לעיון במתכון המתקדם לדוגמה, מציעים למשתמשים טעינה מחדש של הדף.
קובץ השירות (service worker) התחיל לשלוט בדף controlling

כש-Service Worker מעודכן מתחיל לשלוט בדף, המשמעות היא הגרסה של קובץ השירות (service worker) ששולטות כעת שונה הגרסה שהייתה קובעת כשהדף נטען. במקרים מסוימים שעשוי להיות בסדר, אבל יכול להיות גם לכמה נכסים שמתייחסים הדפים הנוכחיים כבר לא נמצאים במטמון (וכנראה שגם לא בשרת). מומלץ ליידע את המשתמש שחלקים מסוימים בדף ייתכן שלא תפעל כראוי.

הערה: האירוע controlling לא יופעל אם לא קוראים לפונקציה skipWaiting() ב-Service Worker.
קובץ השירות (service worker) סיים את ההפעלה activated כאשר קובץ שירות (service worker) מעודכן מסיים את ההפעלה, המשמעות היא הלוגיקה שהרצת ב-activate של קובץ השירות (service worker) הושלמו. אם יש משהו שצריך לדחות עד שהלוגיקה הזו זה הזמן להריץ אותו.

כאשר נמצאה גרסה לא צפויה של Service Worker

לפעמים המשתמשים משאירים את האתר פתוח בכרטיסייה ברקע למשך זמן רב מאוד בזמן האימון. הם עשויים אפילו לפתוח כרטיסייה חדשה ולנווט לאתר בלי לשים לב האתר שלכם כבר פתוח בכרטיסייה ברקע. במקרים כאלה, אפשר להפעיל שתי גרסאות של האתר בו-זמנית, יכול להציג כמה בעיות מעניינות עבורך כמפתח.

נבחן תרחיש שבו כרטיסייה א' מפעילה גרסה 1 של האתר וכרטיסייה ב' הרצה של גרסה 2. כשכרטיסייה ב' נטענת, היא נקבעת על ידי גרסת השירות שלך עובד ששלח עם v1, אך הדף שהוחזר על ידי השרת (אם משתמשים אסטרטגיית שמירה במטמון שמתמקדת ברשת עבור בקשות הניווט) יכללו את כל נכסי V2.

עם זאת, בדרך כלל אין בעיה עם כרטיסייה ב', כי כשכתבת את גרסה 2 הייתם מודעים לאופן הפעולה של קוד גרסה 1 שלכם. עם זאת, עבור כרטיסייה א', מכיוון שקוד גרסה 1 לא היה צפוי לחזות מה עשויים לחול שינויים בקוד גרסה 2 שלכם.

כדי לעזור בהתמודדות עם המצבים האלה, workbox-window שולח גם את מחזור החיים כשהיא מזהה עדכון ממקור "חיצוני" Service Worker, כאשר המשמעות של 'חיצוני' היא כל גרסה שהיא לא הגרסה הנוכחית של Workbox רשום.

החל מגרסה 6 של Workbox ואילך, האירועים האלה מקבילים לאירועים המתועדים למעלה, עם תוספת של נכס isExternal: true שמוגדר לכל אירוע לאובייקט. אם אפליקציית האינטרנט שלכם צריכה להטמיע לוגיקה ספציפית כדי לטפל 'חיצוני' ב-service worker, אפשר לחפש את הנכס הזה בגורמים המטפלים באירועים.

איך להימנע מטעויות נפוצות

אחת התכונות השימושיות ביותר ב-Workbox היא רישום ביומן המפתחים. וגם זה נכון במיוחד לגבי workbox-window.

אנחנו יודעים שפיתוח עם Service Worker יכול להיות מבלבל לעיתים קרובות, ומתי דברים בניגוד למה שציפיתם, לפעמים קשה לדעת למה.

לדוגמה, כשמבצעים שינוי ב-Service Worker וטוענים מחדש את הדף, ייתכן שלא תראו את השינוי הזה בדפדפן שלכם. הסיבה הסבירה ביותר לכך, האם ה-Service Worker עדיין ממתין להפעלה.

אבל כשרושמים קובץ שירות (service worker) לכיתה Workbox, על כל השינויים במצב מחזור החיים במסוף המפתחים, עזרה בניפוי באגים שגורמים להבדלים בציפיות שלכם.

אזהרה לעובד בהמתנה במסוף של חלון תיבת העבודה

נוסף על כך, טעות נפוצה שמפתחים עושים כשהם משתמשים ב-Service Worker בפעם הראשונה היא לרשום קובץ שירות היקף שגוי.

כדי למנוע מצב כזה, תוצג אזהרה בכיתה Workbox אם רישום של קובץ השירות (service worker) לא נכלל בהיקף של אותו קובץ שירות. היא גם להציג אזהרה במקרים שבהם קובץ השירות (service worker) פעיל אך עדיין לא פעיל שליטה בדף:

אזהרה לגבי מסוף של חלון תיבת עבודה לעובד שאינו שליטה

תקשורת של קובץ שירות (service worker) מסוג חלון

השימוש המתקדם ביותר של Service Worker כולל הרבה העברת הודעות בין Service Worker והחלון. גם הכיתה Workbox עוזרת בעניין הזה לספק method messageSW(), שתבטיח postMessage() של המכונה Service Worker רשום וממתינים לתשובה.

אפשר לשלוח נתונים ל-Service Worker בכל פורמט, אבל הפורמט משותף בכל החבילות של Workbox הוא אובייקט בעל שלושה מאפיינים (השניים הבאים אופציונלי):

נכס חובה? סוג תיאור
type כן string

מחרוזת ייחודית, המזהה את ההודעה.

לפי המוסכמה, כל סוגי הסימנים מופיעים באותיות רישיות ומפרידים בין קווים תחתונים ולא של מילים בודדות, אם סוג מייצג פעולה שצריך לבצע, הוא צריך להיות פקודה בזמן הנוכחי (למשל CACHE_URLS), אם הסוג מייצג כשמדווח, זמן צריך להיות בעבר (למשל, URLS_CACHED).
meta לא string ב-Workbox, זהו תמיד השם של חבילת Workbox ששולחת את הודעה. כששולחים הודעה בעצמכם, אפשר להשמיט את המאפיין הזה או להגדיר אותו בכל דרך שתרצו.
payload לא * הנתונים שנשלחים. בדרך כלל זהו אובייקט, אך הוא לא חייב להיות כזה.

בהודעות שנשלחות בשיטה messageSW() נעשה שימוש ב-MessageChannel, כך שהנמען יכולים להגיב. כדי לענות להודעות, אפשר להתקשר event.ports[0].postMessage(response) בהאזנה לאירוע של ההודעה. שיטת messageSW() מחזירה הבטחה שתטפל בכל response אתה משיב.

הנה דוגמה לשליחת הודעות מהחלון ל-Service Worker ו תשובה. בלוק הקוד הראשון הוא האזנה להודעה worker, והבלוק השני משתמש במחלקה Workbox כדי לשלוח את וממתינים לתשובה:

קוד ב-sw.js:

const SW_VERSION = '1.0.0';

addEventListener('message', event => {
  if (event.data.type === 'GET_VERSION') {
    event.ports[0].postMessage(SW_VERSION);
  }
});

הקוד ב-main.js (פועל בחלון):

const wb = new Workbox('/sw.js');
wb.register();

const swVersion = await wb.messageSW({type: 'GET_VERSION'});
console.log('Service Worker version:', swVersion);

ניהול חוסר תאימות של גרסאות

הדוגמה שלמעלה ממחישה איך מטמיעים את בדיקת קובץ השירות (service worker) מהחלון. הדוגמה הזו משמשת מפני שכשאתם שולחים בין החלון וה-Service Worker, זה קריטי חשוב לדעת שיכול להיות שה-Service Worker לא מריץ את אותה גרסה לגבי האתר שקוד הדף פועל בו, והפתרון לבעיה שונה בהתאם לשיטת הצגת הדפים או שמירה במטמון,

קודם רשת

כשמציגים קודם את רשת הדפים, המשתמשים תמיד יקבלו את הגרסה האחרונה של ה-HTML מהשרת שלך. יחד עם זאת, בפעם הראשונה שבה משתמש מבקר שוב באתר שלך (לאחר שפרסת עדכון) קוד ה-HTML שהוא יקבל את הגרסה העדכנית ביותר, אבל Service Worker שפועל בדפדפן שלו גרסה שהותקנה בעבר (כנראה ישנות רבות).

חשוב להבין את האפשרות הזו, כי אם ה-JavaScript נטען על ידי הגרסה הנוכחית של הדף שלך שולח הודעה לגרסה ישנה יותר של Service Worker, ייתכן שהגרסה הזו לא יודעת איך להשיב (או שהיא עשויה להגיב בפורמט שאינו תואם).

לכן כדאי תמיד גרסאות של קובץ השירות (service worker) ולבדוק לגרסאות תואמות לפני ביצוע עבודה חיונית כלשהי.

לדוגמה, בקוד שלמעלה, אם גרסת ה-Service Worker שהוחזרה שיחה אחת (messageSW()) ישנה יותר מהגרסה הצפויה, מומלץ להמתין עד שנמצא עדכון (זה אמור לקרות כשמתקשרים אל register()). בשעה כך אפשר להודיע למשתמש או לעדכן, או לבצע באופן ידני לדלג על שלב ההמתנה כדי להפעיל מיד את ה-Service Worker החדש.

קודם צריך לשמור במטמון

בניגוד להצגה של דפים בעדיפות גבוהה ברשת, כאשר מציגים את הדפים מהמטמון- קודם כל, אתם יודעים שהדף שלכם תמיד יהיה באותה גרסה ה-service worker (כי זה מה ששלח אותו). כתוצאה מכך, כדי להשתמש ב-messageSW() באופן מיידי.

עם זאת, אם נמצאה גרסה מעודכנת של ה-Service Worker ותתבצע הפעלה כשהדף שולח קריאה ל-register() (כלומר מדלגים בכוונה על שלב ההמתנה), ייתכן שכבר לא יהיה בטוח לשלוח אליו הודעות.

אחת האסטרטגיות לניהול האפשרות הזו היא להשתמש בסכמת ניהול גרסאות מאפשרת להבחין בין עדכונים שעלולים לגרום לשיבושים לבין עדכונים לא מכשלים, ובמקרה של עדכון תוכנה שעלול לגרום לכשל, תדעו שלא בטוח לשלוח הודעה Service Worker. במקום זאת, עליך להזהיר את המשתמש שהוא מפעיל גרסה ישנה של הדף, ומציעים להם לטעון מחדש כדי לקבל את העדכון.

דילוג על שלב העוזר בהמתנה

מקובל לשימוש בהודעות מסוג window to Service Worker לצורך שליחת הודעות הודעה אחת ({type: 'SKIP_WAITING'}) כדי להורות ל-Service Worker שמותקן על ידי לדלג על שלב ההמתנה והפעלה.

החל מגרסה 6 של Workbox, אפשר להשתמש ב-method messageSkipWaiting() כדי לשלוח {type: 'SKIP_WAITING'} הודעה לעובדי שירות ההמתנה שמשויך אל רישום קיים של קובץ שירות (service worker). הוא לא יבצע שום פעולה אם אין עובד שירות המתנה.

סוגים

Workbox

כיתה שמסייעת בטיפול ברישום, בעדכונים וב בתגובה לאירועים במחזור החיים של Service Worker.

מאפיינים

  • constructor

    ריק

    יצירת מכונה חדשה של Workbox עם כתובת URL של סקריפט ו-Service Worker אפשרויות. כתובת ה-URL והאפשרויות של הסקריפט זהות לאלה שבהן נעשה שימוש במהלך קוראים לפונקציה navigator.serviceWorker.register(scriptURL, options).

    הפונקציה constructor נראית כך: 

    (scriptURL: string | TrustedScriptURL, registerOptions?: object) => {...}

    • scriptURL

      string | TrustedScriptURL

      הסקריפט של Service Worker שמשויכים למופע הזה. באמצעות יש תמיכה בפרמטר TrustedScriptURL.

    • registerOptions

      אובייקט אופציונלי

  • פעיל

    Promise&lt;ServiceWorker&gt;

  • שליטה

    Promise&lt;ServiceWorker&gt;

  • getSW

    ריק

    מסתיים עם הפניה ל-Service Worker שתואם לכתובת ה-URL של הסקריפט של המופע הזה, ברגע שהוא זמין.

    אם בזמן הרישום כבר יש שירות פעיל או שירות המתנה עם כתובת URL תואמת של סקריפט, הוא ישמש (עם המתנה קובץ שירות (service worker) מקבל עדיפות על פני ה-Service Worker אם שניהם בהתאמה, מכיוון שעובד שירות המתנה היה רשום יותר לאחרונה). אם אין עובד שירות תואם או פעיל בזמן הרישום ואז ההבטחה לא תפוג עד שיימצא עדכון ויתחיל ובשלב הזה ייעשה שימוש ב-Service Worker להתקנה.

    הפונקציה getSW נראית כך: 

    () => {...}

    • החזרות

      Promise&lt;ServiceWorker&gt;

  • messageSW

    ריק

    שליחת אובייקט הנתונים שהועבר ל-Service Worker שרשום על ידי מופע (דרך workbox-window.Workbox#getSW) ומקודד עם תגובה (אם בכלל).

    אפשר להגדיר תשובה ב-handler של הודעות ב-Service Worker באמצעות התקשרות אל event.ports[0].postMessage(...), והפעולה הזו תפתור את ההבטחה הוחזרה על ידי messageSW(). אם לא תוגדר תגובה, ההבטחה אף פעם לא לפתור את הבעיה.

    הפונקציה messageSW נראית כך: 

    (data: object) => {...}

    • נתונים

      אובייקט

      אובייקט לשליחה ל-Service Worker

    • החזרות

      הבטחה<כלשהו>

  • messageSkipWaiting

    ריק

    נשלחת הודעת {type: 'SKIP_WAITING'} ל-Service Worker נמצאים כרגע במצב waiting שמשויך לרישום הנוכחי.

    אם אין רישום נוכחי או שאין קובץ שירות (service worker) הוא waiting, לקריאה הזו לא תהיה השפעה.

    הפונקציה messageSkipWaiting נראית כך: 

    () => {...}

  • להירשם

    ריק

    רושם קובץ שירות (service worker) עבור כתובת ה-URL והשירות של הסקריפט של המופע הזה אפשרויות לעובדים. כברירת מחדל, השיטה הזו מעכבת את ההרשמה עד מאוחר יותר החלון נטען.

    הפונקציה register נראית כך: 

    (options?: object) => {...}

    • אפשרויות

      אובייקט אופציונלי

      • מיידי

        ערך בוליאני אופציונלי

    • החזרות

      Promise&lt;ServiceWorkerRegistration&gt;

  • עדכון

    ריק

    חיפוש עדכונים של Service Worker הרשום.

    הפונקציה update נראית כך: 

    () => {...}

    • החזרות

      הבטחה<Empty>

WorkboxEventMap

מאפיינים

WorkboxLifecycleEvent

מאפיינים

  • isExternal

    ערך בוליאני אופציונלי

  • isUpdate

    ערך בוליאני אופציונלי

  • originalEvent

    אירוע אופציונלי

  • sw

    ServiceWorker אופציונלי

  • יעד

    WorkboxEventTarget אופציונלי

  • סוג

    typeOperator

WorkboxLifecycleEventMap

מאפיינים

WorkboxLifecycleWaitingEvent

מאפיינים

  • isExternal

    ערך בוליאני אופציונלי

  • isUpdate

    ערך בוליאני אופציונלי

  • originalEvent

    אירוע אופציונלי

  • sw

    ServiceWorker אופציונלי

  • יעד

    WorkboxEventTarget אופציונלי

  • סוג

    typeOperator

  • wasWaitingBeforeRegister

    ערך בוליאני אופציונלי

WorkboxMessageEvent

מאפיינים

  • נתונים

    כל

  • isExternal

    ערך בוליאני אופציונלי

  • originalEvent

    אירוע

  • ports

    typeOperator

  • sw

    ServiceWorker אופציונלי

  • יעד

    WorkboxEventTarget אופציונלי

  • סוג

    "message"

שיטות

messageSW()

workbox-window.messageSW(
  sw: ServiceWorker,
  data: object,
)

שליחת אובייקט נתונים ל-Service Worker דרך postMessage ומסומנת ב- תשובה (אם בכלל).

אפשר להגדיר תשובה ב-handler של הודעות ב-Service Worker באמצעות התקשרות אל event.ports[0].postMessage(...), והפעולה הזו תפתור את ההבטחה הוחזרה על ידי messageSW(). אם לא תוגדר תגובה, ההבטחה לא לפתור את הבעיה.

פרמטרים

  • sw

    ServiceWorker

    קובץ השירות (service worker) שאליו יש לשלוח את ההודעה.

  • נתונים

    אובייקט

    אובייקט לשליחה ל-Service Worker.

החזרות

  • הבטחה<כלשהו>