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

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

generateSW מול injectManifest

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

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

מתי להשתמש במאפיין generateSW

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

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

מתי לא להשתמש בgenerateSW

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

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

מתי להשתמש במאפיין injectManifest

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

• אתם רוצים לשמור קבצים במטמון, אבל רוצים לכתוב Service Worker משלכם.
• יש לך צורכי שמירה מורכבים במטמון או בניתוב שאי אפשר לבטא באמצעות אפשרויות ההגדרה של generateSW
• אתם רוצים להשתמש בממשקי API אחרים ב-Service Worker (כמו Web Push).

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

מתי לא להשתמש בinjectManifest

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

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

שימוש בכלי ה-build של Workbox

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

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

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

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'
});

בדוגמה שלמעלה, ה-Service Worker שנוצר ייכתב בספרייה dist על ידי workbox-build כשמריצים את הפקודה node build-sw.mjs.

שימוש ב-bundler

ל-Bunders שונים יש יישומי פלאגין משלהם ל-Workbox, אבל ה-bundler היחיד שנתמך באופן רשמי על ידי צוות Workbox הוא webpack, דרך workbox-webpack-plugin. בדומה ל-workbox-cli ול-workbox-build, גם workbox-webpack-plugin יפעיל את ה-methods 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 כבר יודע איפה מקובצים נכסי הייצור שלכם.

שימוש ב-framework

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

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

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

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

סיכום

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