הדרכים של תיבת העבודה

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

generateSW נגד injectManifest

תהיה לך אפשרות להשתמש באחת משתי שיטות הליבה של כלי ה-build של Workbox: generateSW או injectManifest. האפשרות שבה כדאי להשתמש תלויה ברמת הגמישות הדרושה. generateSW נותנת עדיפות לנוחות השימוש ולפשטות במחיר של הגמישות, וכך מאפשרת לכם להצהיר על קבוצה של אפשרויות הגדרה ולקבל בתמורה קובץ שירות (service worker) בעל פונקציונליות מלאה.

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

מתי להשתמש בgenerateSW

כדאי להשתמש בgenerateSW אם:

• כאשר רוצים לשמור מראש קבצים שמשויכים לתהליך ה-build, כולל קבצים שכתובות ה-URL שלהם מכילות גיבובים (hash) שייתכן שלא ידעתם מראש.
• יש לכם צרכים פשוטים לשמירה במטמון בזמן הריצה. אפשר להגדיר אותם באמצעות האפשרויות של generateSW.

באילו מקרים לא להשתמש ב-generateSW

מצד שני, לא כדאי להשתמש ב-generateSW אם:

• כשרוצים להשתמש בתכונות אחרות של קובץ השירות (service worker) (כמו Web Push).
• כדי לייבא סקריפטים נוספים או להשתמש במודולים ספציפיים של Workbox, דרושות לכם גמישות נוספת כדי להתאים את Service Worker לצרכים של האפליקציה שלכם.

מתי להשתמש בinjectManifest

כדאי להשתמש בinjectManifest אם:

• אתם רוצים לשמור קבצים במטמון, אבל רוצים לכתוב קובץ שירות (service worker) משלכם.
• יש לך צרכים מורכבים בשמירה במטמון או בניתוב, שלא ניתן לבטא באפשרויות התצורה של generateSW
• ברצונך להשתמש בממשקי API אחרים בקובץ השירות (כגון Web Push).

injectManifest שונה מ-generateSW בכך שהוא מחייב לציין קובץ שירות מקור. בתהליך העבודה הזה, קובץ ה-Service Worker של המקור צריך לכלול מחרוזת self.__WB_MANIFEST מיוחדת כדי לאפשר ל-injectManifest להחליף אותו במניפסט של המטמון מראש.

באילו מקרים לא להשתמש ב-injectManifest

לא מומלץ להשתמש ב-injectManifest אם:

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

שימוש בכלי Build של Workbox

יש לכם שלוש אפשרויות לשימוש ב-Workbox בתהליך ה-build, אבל מחפשים דרך שאינה מבוססת על framework:

1. workbox-cli
2. workbox-build. כלי שורת הפקודה.
3. שימוש ב-bundler (כמו workbox-webpack-plugin).

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

workbox-cli

אם אתם מחפשים את חסם הכניסה הנמוך ביותר שאפשר עם Workbox, ה-CLI הוא בשבילכם:

npm install workbox-cli --save-dev

כדי להתחיל להשתמש ב-CLI, מריצים את האשף עם npx workbox wizard. האשף ישאל כמה שאלות, והתשובות לשאלות האלה ישמשו להגדרת פרויקט עם קובץ workbox-config.js שתוכלו להתאים אישית לצרכים שלכם. זה ייראה בערך כך:

// A config for `generateSW`
export default {
  globDirectory: 'dist/',
  globPatterns: [
    '**/*.{css,woff2,png,svg,jpg,js}'
  ],
  swDest: 'dist/sw.js'
};

לאחר יצירת קובץ התצורה, ה-CLI יכול להריץ בשבילך שיטות generateSW או injectManifest. טקסט העזרה של ה-CLI כולל מידע נוסף ודוגמאות לשימוש.

workbox-build

workbox-cli הוא wrapper מסביב למודול workbox-build, וחלופה היא להשתמש workbox-buildישירות. כשמשתמשים ב-workbox-build, במקום לציין אפשרויות באמצעות קובץ workbox-config.js, צריך להשתמש בשיטות generateSW או injectManifest ישירות כחלק מסקריפט של צומת, תוך העברה של קבוצת אפשרויות דומה:

// build-sw.mjs
import {generateSW} from 'workbox-build';

generateSW({
  globDirectory: 'dist/',
  globPatterns: [
    '**/*.{css,woff2,png,svg,jpg,js}'
  ],
  swDest: 'dist/sw.js'
});

בדוגמה שלמעלה, workbox-build יכתוב את קובץ השירות (service worker) שנוצר בספרייה dist כאשר תרוץ הפקודה node build-sw.mjs.

שימוש ב-bundler

ל-Bundlers שונים יש יישומי פלאגין משלהם של Workbox, אבל ה-bundler היחיד שנתמך באופן רשמי על ידי צוות Workbox הוא Webpack, דרך workbox-webpack-plugin. בדומה ל-workbox-cli ו-workbox-build, workbox-webpack-plugin יריץ את השיטות generateSW או injectManifest, אלא שהפלאגין משתמש באותיות רישיות בשמות השיטות האלה כ-GenerateSW או InjectManifest. אם לא, השימוש דומה ל-workbox-build:

// webpack.config.js
import {GenerateSW} from 'workbox-webpack-plugin';

export default {
  // Other webpack config options omitted for brevity...
  plugins: [
    new GenerateSW({
      swDest: './dist/sw.js'
    })
  ]
};

האפשרויות שמעבירים אל GenerateSW או אל InjectManifest לא זהות לאלה של generateSW או injectManifest, אבל יש חפיפה משמעותית. באופן ספציפי, אתם לא צריכים לציין את האפשרות globDirectory עבור GenerateSW – וגם אתם לא צריכים לציין אותה, כי חבילת ה-Webpack כבר יודעת איפה הנכסים בסביבת הייצור מקובצים.

שימוש במסגרת

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

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

מה לעשות אם אין לי תהליך build?

ההנחה במסמך זה היא שלפרויקט שלכם יש תהליך build, אבל ייתכן שלא. אם תיאור זה מתאים למצב שלכם, עדיין ניתן להשתמש ב-Workbox עם המודול workbox-sw. באמצעות workbox-sw, אפשר לטעון את זמן הריצה של Workbox מ-CDN או באופן מקומי ולהרכיב קובץ שירות (service worker) משלך.

סיכום

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