למפתחים שהשתמשו בעבר ב-sw-precache
ו/או ב-sw-toolbox
יש נתיב שדרוג פשוט למשפחת הספריות של Workbox. השדרוג ל-Workbox יספק חוויה מודרנית של Service Worker, עם הרחבת ניפוי באגים וארגונומית מפתחים.
שינויים בהגדרות הקיימות
אם משתמשים ב-sw-precache
שמוגדרת בו אחת מהאפשרויות הבאות, צריך להביא בחשבון את השינויים הבאים במסגרת המעבר ל-Workbox.
אפשרויות שהשם שלהן השתנה
השם של פרמטר ההגדרה dynamicUrlToDependencies
השתנה ל-templatedURLs
.
השם של פרמטר ההגדרה staticFileGlobs
השתנה ל-globPatterns
.
הפרמטר של התצורה runtimeCaching
מקבל קבוצת אפשרויות מעודכנת, בהתאם לשמות שבהם נעשה שימוש במודולים של תיבת העבודה הבסיסית. כדי להמחיש את השם של השינוי, ההגדרה הזו של sw-precache
:
runtimeCaching: [{
urlPattern: /api/,
handler: 'fastest',
options: {
cache: {
name: 'my-api-cache',
maxEntries: 5,
maxAgeSeconds: 60,
},
},
}],
זהה לתצורה הבאה של Workbox:
runtimeCaching: [{
urlPattern: /api/,
// 'fastest' is now 'StaleWhileRevalidate'
handler: 'StaleWhileRevalidate',
options: {
// options.cache.name is now options.cacheName
cacheName: 'my-api-cache',
// options.cache is now options.expiration
expiration: {
maxEntries: 5,
maxAgeSeconds: 60,
},
},
}],
אפשרויות שהוצאו משימוש
אין יותר תמיכה במסלולים עם תווים כלליים לחיפוש בסגנון אקספרס. אם השתמשת בנתיבים עם תווים כלליים בסגנון Express בתצורה runtimeCaching
או ישירות ב-sw-toolbox
, עליך לעבור למסלול מקביל של ביטוי רגולרי כשמשתמשים בתיבת עבודה.
העברות Sw-precache
מ-sw-precache CLI ל-workbox-cli
מפתחים שמשתמשים בממשק שורת הפקודה sw-precache
, בין אם מריצים את הפקודה באופן ידני או כחלק מתהליך build מבוסס npm scripts
, יגלו שהשימוש במודול workbox-cli
הוא הדרך הקלה ביותר לבצע את ההעברה. התקנת workbox-cli
תעניק לך גישה לקובץ בינארי שנקרא workbox
.
ב-CLI של sw-precache
נתמך על ידי קביעת תצורה באמצעות דגלי שורת פקודה או קובץ תצורה, אך ה-CLI של workbox
דורש שכל אפשרויות התצורה יסופקו בקובץ תצורה, באמצעות CommonJS module.exports
.
CLI של workbox
תומך במספר מצבים שונים. (כדי לראות את כולם צריך להשתמש ב-workbox --help
). אבל המצב שהכי מתאים לפונקציונליות של sw-precache
הוא generateSW
. אז קריאה
$ sw-precache --config='sw-precache-config.js'
אפשר לבטא בצורה
$ workbox generateSW workbox-config.js
ממודול הצומת sw-precache למודול הצומת של workbox-build
מפתחים שמשתמשים ב-API של node
עבור sw-precache
, כחלק מתהליך עבודה של gulp
/Grunt
או רק בתוך סקריפט build מותאם אישית של node
, יכולים לבצע את ההעברה על ידי מעבר למודול workbox-build
של node
.
הפונקציה generateSW()
של המודול workbox-build
תואמת במידה הרבה ביותר את הפונקציה write()
של המודול sw-precache
. הבדל משמעותי אחד הוא ש-generateSW()
מחזירה תמיד Promise (הבטחה), בעוד שהפונקציה write()
הישנה תמכה גם בקריאה חוזרת (callback) וגם בממשק מבוסס-Promise (הבטחה).
שימוש ב-gulp
במקביל
const swPrecache = require('sw-precache');
gulp.task('generate-service-worker', function () {
return swPrecache.write('service-worker.js', {
// Config options.
});
});
ניתן לשנות ל-
const workboxBuild = require('workbox-build');
gulp.task('generate-service-worker', function () {
return workboxBuild.generateSW({
// Config options.
});
});
מהפלאגין של sw-precache-webpack_in אל הפלאגין Workbox Webpack
מפתחים שמשתמשים ב-sw-precache-webpack-plugin
כחלק מתהליך ה-build של Webpack יכולים לעבור למחלקה GenerateSW
במודול workbox-webpack-plugin
.
workbox-webpack-plugin
משתלב ישירות בתהליך ה-build של ה-Webpack ו "מכיר" את כל הנכסים שנוצרו על ידי אוסף נתון. כלומר, בתרחישים רבים לדוגמה, אפשר להסתמך על התנהגות ברירת המחדל של workbox-webpack-plugin
ללא הגדרות נוספות, ולקבל קובץ שירות (service worker) מקביל למה ש-sw-precache-webpack-plugin
מספק.
const SWPrecacheWebpackPlugin = require('sw-precache-webpack-plugin');
const webpackConfig = {
// ...
plugins: [
new SWPrecacheWebpackPlugin({
dontCacheBustUrlsMatching: /\.\w{8}\./,
filename: 'service-worker.js',
}),
],
};
ניתן לשנות ל-
const {GenerateSW} = require('workbox-webpack-plugin');
const webpackConfig = {
// ...
plugins: [
new GenerateSW({
// Config options, if needed.
}),
],
};
העברות Sw-toolbox
מעבר מ-sw-toolbox בעבודת יד ל-workbox-sw
אם השתמשת ב-sw-toolbox
ישירות (במקום להשתמש בו באופן מרומז דרך האפשרות runtimeCaching
של sw-precache
), ההעברה ל-Workbox מחייבת ביצוע התאמות ידניות כדי לקבל את ההתנהגות המקבילה. הקשר נוסף זמין במסמכי התיעוד של המודולים workbox-routing
ו-workbox-strategies
.
לפניכם כמה קטעי קוד שיעזרו לכם לבצע את ההעברה. הקוד הזה של sw-toolbox
:
importScripts('path/to/sw-toolbox.js');
// Set up a route that matches HTTP 'GET' requests.
toolbox.router.get(
// Match any URL that contains 'ytimg.com', regardless of
// where in the URL that match occurs.
/\.ytimg\.com\//,
// Apply a cache-first strategy to anything that matches.
toolbox.cacheFirst,
{
// Configure a custom cache name and expiration policy.
cache: {
name: 'youtube-thumbnails',
maxEntries: 10,
maxAgeSeconds: 30,
},
}
);
// Set a default network-first strategy to use when
// there is no explicit matching route:
toolbox.router.default = toolbox.networkFirst;
שווה ערך לקוד תיבת העבודה הבא:
importScripts('path/to/workbox-sw.js');
workbox.routing.registerRoute(
// Match any URL that contains 'ytimg.com'.
// Unlike in sw-toolbox, in Workbox, a RegExp that matches
// a cross-origin URL needs to include the initial 'https://'
// as part of the match.
new RegExp('^https://.*.ytimg.com'),
// Apply a cache-first strategy to anything that matches.
new workbox.strategies.CacheFirst({
// Configuration options are passed in to the strategy.
cacheName: 'youtube-thumbnails',
plugins: [
new workbox.expiration.ExpirationPlugin({
maxEntries: 10,
maxAgeSeconds: 30,
}),
// In Workbox, you must explicitly opt-in to caching
// responses with a status of 0 when using the
// cache-first strategy.
new workbox.cacheableResponse.CacheableResponsePlugin({
statuses: [0, 200],
}),
],
})
);
// Set a default network-first strategy to use when
// there is no explicit matching route:
workbox.routing.setDefaultHandler(new workbox.strategies.NetworkFirst());
קבלת עזרה
אנחנו צופים שרוב ההעברות ל-Workbox יהיו פשוטות. אם תיתקלו בבעיות שלא מצאתם להן תשובה במדריך הזה, תוכלו לפתוח את הבעיה ב-GitHub.