סביבת העבודה גמישה מספיק כדי להתאים כמעט לכל תהליך ה-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:
workbox-cli
workbox-build
. כלי שורת הפקודה.- שימוש ב-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) עם תכונות מתקדמות יותר במקרה הצורך.