אפליקציות Progressive Web App: עבודה עם Workbox

1. שלום

בשיעור Lab הזה, תלמדו איך לקחת אתר עם קובץ שירות (service worker) קיים ולהמיר אותו לשימוש ב-Workbox. ה-codelab הזה הוא השני בסדרת codelabs נלווים לסדנת Progressive Web App. ה-codelab הקודם היה Going Offline. יש עוד שישה שיעורי Codelab בסדרה הזו.

מה תלמדו

  • המרת Service Worker קיים לשימוש ב-Workbox
  • הוספת חלופה אופליין ל-PWA

מה חשוב לדעת

  • HTML ו-JavaScript בסיסיים

מה צריך

2. טיפים להגדרה

כדי להתחיל, משכפלים או מורידים את הקוד לתחילת הדרך שנדרש להשלמת ה-Codelab הזה:

אם משכפלים את המאגר, חשוב לוודא שנמצאים בהסתעפות pwa03--workbox. קובץ ה-ZIP מכיל גם את הקוד של הענף הזה.

בסיס הקוד הזה דורש Node.js בגרסה 14 ומעלה. אחרי שהקוד זמין, מריצים את הפקודה npm ci משורת הפקודה בתיקיית הקוד כדי להתקין את כל התלויות שצריך. לאחר מכן, מריצים את הפקודה npm start כדי להפעיל את שרת הפיתוח של ה-codelab.

קובץ README.md של קוד המקור מספק הסבר לכל הקבצים המופצים. בנוסף, אלה הקבצים הקיימים העיקריים שתעבדו איתם במהלך ה-codelab הזה:

קבצים חשובים

  • ‫service-worker.js – קובץ service worker של האפליקציה
  • ‫offline.html – קובץ HTML אופליין לשימוש כשדף לא זמין

3. העברה ל-Workbox

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

  • שמירת קבצים רלוונטיים במטמון במהלך ההתקנה של Service Worker
  • הצגת הקבצים האלה שוב באמצעות אסטרטגיה של מטמון בלבד

עדיין כדאי לבצע שמירה מראש במטמון של הקובץ index.html ושל המסלול /, כי קובצי ה-HTML של אפליקציית האינטרנט הזו לא ישתנו הרבה. אבל הקבצים האחרים, כמו CSS ו-JavaScript, עשויים להשתנות, ואנחנו לא רוצים לעבור את כל מחזור החיים של Service Worker בכל פעם שהם משתנים. בנוסף, ה-Service Worker הנוכחי מתייחס רק לקבוצת משנה של קובצי ה-CSS וה-JavaScript שלנו, ואנחנו רוצים שהוא יתייחס לכולם. הגיוני יותר לשמור את הפריטים האלה במטמון באמצעות אסטרטגיית 'מאוחסן במטמון עד לאימות מחדש': תגובה מהירה שאפשר לעדכן ברקע לפי הצורך.

הסבר על טרום-שמירה במטמון

כשמעבירים ל-Workbox, אין צורך לשמור את הקוד הקיים, לכן צריך למחוק את כל מה שמופיע ב-service-worker.js. בשיעור ה-Lab הקודם הגדרנו את Service Worker הזה כך שיעבור קומפילציה, כדי שנוכל להשתמש כאן בייבוא של ESModule כדי להוסיף את Workbox מהמודולים שלו ב-NPM. נתחיל בבדיקה של טרום-שמירה במטמון. ב-service-worker.js, מוסיפים את הקוד הבא:

import { warmStrategyCache } from 'workbox-recipes';
import { CacheFirst } from 'workbox-strategies';
import { registerRoute } from 'workbox-routing';
import { CacheableResponsePlugin } from 'workbox-cacheable-response';
import { ExpirationPlugin } from 'workbox-expiration';

// Set up page cache
const pageCache = new CacheFirst({
  cacheName: 'page-cache',
  plugins: [
    new CacheableResponsePlugin({
      statuses: [0, 200],
    }),
    new ExpirationPlugin({
      maxAgeSeconds: 30 * 24 * 60 * 60,
    }),
  ],
});

warmStrategyCache({
  urls: ['/index.html', '/'],
  strategy: pageCache,
});

registerRoute(({ request }) => request.mode === 'navigate', pageCache);

הסבר

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

הוא מתחיל בהגדרה של אסטרטגיית שמירה במטמון מסוג Cache First (מטמון תחילה), שנבחרה במקום אסטרטגיית Cache Only (מטמון בלבד) כדי לאפשר הוספה של דפים אחרים למטמון לפי הצורך. ניתן לו שם, page-cache. אסטרטגיות Workbox יכולות להשתמש במספר תוספים שיכולים להשפיע על מחזור החיים של שמירת תוכן באחסון הנתונים הזמני ואחזור שלו ממנו. בדוגמה הזו נעשה שימוש בשני תוספים, Cacheable Response ו-Expiration, כדי לוודא שרק תגובות טובות של השרת נשמרות במטמון, ושהמערכת תמחק כל פריט במטמון אחרי 30 יום.

לאחר מכן, המטמון של השיטה מתמלא באמצעות /index.html ו-/ באמצעות המתכון של Workbox למילוי המטמון של השיטה. הפריטים האלה יתווספו למטמון במהלך אירוע ההתקנה של ה-service worker.

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

שמירת נכסים במטמון

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

// Set up asset cache
registerRoute(
  ({ request }) => ['style', 'script', 'worker'].includes(request.destination),
  new StaleWhileRevalidate({
    cacheName: 'asset-cache',
    plugins: [
      new CacheableResponsePlugin({
        statuses: [0, 200],
      }),
    ],
  }),
);

הסבר

המסלול הזה מתחיל בקביעה אם סוג הבקשה הוא סגנון, סקריפט או worker, שמתאים ל-CSS, ל-JavaScript או ל-Web Workers. אם כן, המערכת משתמשת באסטרטגיית 'לא עדכני אבל עדיין תקף' (Stale While Revalidate). היא מנסה להציג את התוכן מהמטמון קודם, ואם הוא לא זמין, היא חוזרת לרשת. במקביל, היא מנסה לעדכן את הגרסה במטמון מהרשת, אם אפשר. בדומה לאסטרטגיית הדפים, האסטרטגיה הזו תאחסן במטמון רק תגובות טובות.

4. הוספת חלופה אופליין

אחרי שהעברנו את ה-service worker המקורי ל-Workbox, יש עוד דבר אחד שצריך לעשות כדי למנוע קריסה של ה-PWA במצב אופליין: הוספת חלופה למצב אופליין.

אפשר להגדיר חלופות אופליין לכל מה שעשוי לא להיות זמין במצב אופליין: דפים, גופנים, CSS,‏ JavaScript, תמונות וכו'. לפחות צריך להגדיר חזרה לדף לכל אפליקציות ה-PWA, כדי שאם משתמש ינווט לדף שלא נמצא במטמון, הוא יישאר בהקשר של האפליקציה.

מתכוני Workbox מספקים מתכון חלופי במצב אופליין שאפשר להשתמש בו כדי לעשות בדיוק את זה! כדי להשתמש בו, קודם מוסיפים את offlineFallback לייבוא של workbox-recipes, ואז מוסיפים את הקוד הבא לחלק התחתון של Service Worker:

// Set up offline fallback
offlineFallback({
  pageFallback: '/offline.html',
});

הסבר

המתכון לגיבוי אופליין מגדיר אסטרטגיה של Cache Only (מטמון בלבד) שמתמלאת בגיבויים שסופקו. לאחר מכן, הוא מגדיר את handler ברירת המחדל של Workbox לטיפול בשגיאות, ומטפל בכל בקשות הניתוב שנכשלו (אם אין כלום במטמון ולא ניתן להגיע למשהו ברשת). הוא שולף את התוכן של הקבצים הרלוונטיים מהמטמון ומחזיר אותו כתוכן כל עוד הבקשה ממשיכה להיכשל.

5. מעולה!

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

הקוד לאב הבא בסדרה הוא IndexedDB