Das Modul workbox-sw bietet eine extrem einfache Möglichkeit für den Einstieg in die Workbox-Module, vereinfacht das Laden der Workbox-Module und bietet einige einfache Hilfsmethoden.
Sie können workbox-sw über unser CDN oder eine Reihe von Workbox-Dateien auf Ihrem eigenen Server verwenden.
Workbox SW über CDN verwenden
Der Einstieg in dieses Modul ist am einfachsten über das CDN. Sie müssen Ihrem Service Worker lediglich Folgendes hinzufügen:
importScripts(
'https://storage.googleapis.com/workbox-cdn/releases/6.4.1/workbox-sw.js'
);
Damit haben Sie den Namespace workbox in Ihrem Service Worker, der Zugriff auf alle Workbox-Module bietet.
workbox.precaching.*
workbox.routing.*
etc
Sobald Sie mit der Verwendung der zusätzlichen Module beginnen, erhalten Sie eine gewisse Magie.
Wenn Sie zum ersten Mal auf ein Modul verweisen, erkennt workbox-sw dies und lädt das Modul, bevor es verfügbar gemacht wird. Du kannst das in den Entwicklertools
auf dem Tab „Netzwerk“ sehen.
Diese Dateien werden von Ihrem Browser im Cache gespeichert, sodass sie für die zukünftige Offlinenutzung verfügbar sind.
Lokale Workbox-Dateien anstelle von CDN verwenden
Wenn Sie das CDN nicht verwenden möchten, ist es einfach genug, zu Workbox-Dateien zu wechseln, die auf Ihrer eigenen Domain gehostet werden.
Der einfachste Ansatz besteht darin, die Dateien mit dem Befehl copyLibraries von workbox-cli abzurufen und dann workbox-sw über die Konfigurationsoption modulePathPrefix mitzuteilen, wo die Dateien zu finden sind.
Wenn Sie die Dateien unter /third_party/workbox-vX.Y.Z/ ablegen, würden Sie sie so verwenden:
importScripts('/third_party/workbox-vX.Y.Z/workbox-sw.js');
workbox.setConfig({
modulePathPrefix: '/third_party/workbox-vX.Y.Z/',
});
Asynchrone Importe vermeiden
Um neue Module zum ersten Mal zu laden, muss importScripts() mit dem Pfad zur entsprechenden JavaScript-Datei aufgerufen werden (entweder im CDN oder über eine lokale URL).
In beiden Fällen gilt eine wichtige Einschränkung: Die impliziten Aufrufe von importScripts() können nur innerhalb des install-Handlers eines Service Workers oder während der synchronen, ersten Ausführung des Service Worker-Skripts erfolgen.
Um Verstöße gegen diese Einschränkung zu vermeiden, empfiehlt es sich, außerhalb von Event-Handlern oder asynchronen Funktionen auf die verschiedenen workbox.*-Namespaces zu verweisen.
Der folgende Service Worker-Code der obersten Ebene ist beispielsweise zulässig:
importScripts(
'https://storage.googleapis.com/workbox-cdn/releases/6.4.1/workbox-sw.js'
);
// This will work!
workbox.routing.registerRoute(
({request}) => request.destination === 'image',
new workbox.strategies.CacheFirst()
);
Der folgende Code kann jedoch ein Problem sein, wenn Sie an anderer Stelle im Service Worker nicht auf workbox.strategies verwiesen haben:
importScripts(
'https://storage.googleapis.com/workbox-cdn/releases/6.4.1/workbox-sw.js'
);
self.addEventListener('fetch', event => {
if (event.request.url.endsWith('.png')) {
// Oops! This causes workbox-strategies.js to be imported inside a fetch handler,
// outside of the initial, synchronous service worker execution.
const cacheFirst = new workbox.strategies.CacheFirst();
event.respondWith(cacheFirst.handle({request: event.request}));
}
});
Wenn Sie Code schreiben müssen, der ansonsten gegen diese Einschränkung verstoßen würde, können Sie den importScripts()-Aufruf mit der Methode workbox.loadModule() explizit außerhalb des Event-Handlers auslösen:
importScripts(
'https://storage.googleapis.com/workbox-cdn/releases/6.4.1/workbox-sw.js'
);
// This will trigger the importScripts() for workbox.strategies and its dependencies:
workbox.loadModule('workbox-strategies');
self.addEventListener('fetch', event => {
if (event.request.url.endsWith('.png')) {
// Referencing workbox.strategies will now work as expected.
const cacheFirst = new workbox.strategies.CacheFirst();
event.respondWith(cacheFirst.handle({request: event.request}));
}
});
Alternativ können Sie einen Verweis auf die relevanten Namespaces außerhalb Ihrer Event-Handler erstellen und diese Referenz später verwenden:
importScripts(
'https://storage.googleapis.com/workbox-cdn/releases/6.4.1/workbox-sw.js'
);
// This will trigger the importScripts() for workbox.strategies and its dependencies:
const {strategies} = workbox;
self.addEventListener('fetch', event => {
if (event.request.url.endsWith('.png')) {
// Using the previously-initialized strategies will work as expected.
const cacheFirst = new strategies.CacheFirst();
event.respondWith(cacheFirst.handle({request: event.request}));
}
});
Verwendung von Debug- oder Produktions-Builds erzwingen
Alle Workbox-Module enthalten zwei Builds: einen Debug-Build, der Logging und zusätzliche Typprüfungen enthält, und einen Produktions-Build, der Logging und Typprüfung verkürzt.
Standardmäßig verwendet workbox-sw den Build zur Fehlerbehebung für Websites auf localhost, aber für jeden anderen Ursprung wird der Produktions-Build verwendet.
Wenn Sie die Fehlerbehebung oder Produktions-Builds erzwingen möchten, können Sie die Konfigurationsoption debug festlegen:
workbox.setConfig({
debug: true,
});
Code mithilfe von Importanweisungen zur Verwendung von workbox-sw konvertieren
Beim Laden von Workbox mit workbox-sw wird über den globalen workbox.*-Namespace auf alle Workbox-Pakete zugegriffen.
Wenn Sie ein Codebeispiel mit import-Anweisungen haben, die Sie in workbox-sw umwandeln möchten, müssen Sie nur workbox-sw laden und alle import-Anweisungen durch lokale Variablen ersetzen, die auf diese Module im globalen Namespace verweisen.
Das funktioniert, da jedes in npm veröffentlichte Workbox-Service-Worker-Paket auch im globalen Namespace workbox über eine camelCase-Version des Namens verfügbar ist (z.B. alle Module, die aus dem workbox-precaching-npm-Paket exportiert wurden) finden Sie unter workbox.precaching.*. Alle Module, die aus dem npm-Paket workbox-background-sync exportiert wurden, finden Sie unter workbox.backgroundSync.*.
Im Folgenden finden Sie als Beispiel Code, der import-Anweisungen verwendet, die auf Workbox-Module verweisen:
import {registerRoute} from 'workbox-routing';
import {CacheFirst} from 'workbox-strategies';
import {CacheableResponse} from 'workbox-cacheable-response';
registerRoute(
({request}) => request.destination === 'image',
new CacheFirst({
plugins: [new CacheableResponsePlugin({statuses: [0, 200]})],
})
);
Hier ist der gleiche Code umgeschrieben mit workbox-sw (beachten Sie, dass sich nur die Importanweisungen geändert haben – die Logik wurde nicht verändert):
importScripts(
'https://storage.googleapis.com/workbox-cdn/releases/6.4.1/workbox-sw.js'
);
const {registerRoute} = workbox.routing;
const {CacheFirst} = workbox.strategies;
const {CacheableResponse} = workbox.cacheableResponse;
registerRoute(
({request}) => request.destination === 'image',
new CacheFirst({
plugins: [new CacheableResponsePlugin({statuses: [0, 200]})],
})
);