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

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

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

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

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

נקודת הכניסה הראשית לחבילה 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

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

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

כאשר נמצאה גרסה לא צפויה של 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 הוא אובייקט בעל שלושה מאפיינים (השניים הבאים אופציונלי):

בהודעות שנשלחות בשיטה 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-window.messageSW(
  sw: ServiceWorker,
  data: object,
)