ExtendableEvent
Baseline Widely available
This feature is well established and works across many devices and browser versions. It’s been available across browsers since April 2018.
Hinweis: Dieses Feature ist nur verfügbar in Service Workers.
Das ExtendableEvent
-Interface verlängert die Lebensdauer der install
und activate
Ereignisse, die im globalen Kontext als Teil des Service-Worker-Lebenszyklus ausgelöst werden. Dies stellt sicher, dass keine funktionalen Ereignisse (wie FetchEvent
) gesendet werden, bis Datenbankschemata aktualisiert und veraltete Cache-Einträge gelöscht wurden.
Wenn waitUntil()
außerhalb des ExtendableEvent
-Handlers aufgerufen wird, sollte der Browser einen InvalidStateError
werfen; beachten Sie auch, dass mehrfache Aufrufe gestapelt werden, und die resultierenden Versprechen der Liste der Lebenszeit-Verlängerungsversprechen hinzugefügt werden.
Dieses Interface erbt vom Event
-Interface.
Hinweis: Dieses Interface ist nur verfügbar, wenn der globale Kontext ein ServiceWorkerGlobalScope
ist. Es ist nicht verfügbar, wenn es ein Window
oder der Kontext einer anderen Art von Worker ist.
Konstruktor
ExtendableEvent()
-
Erstellt ein neues
ExtendableEvent
-Objekt.
Instanz-Eigenschaften
Implementiert keine spezifischen Eigenschaften, erbt aber Eigenschaften von seinem Elternteil, Event
.
Instanz-Methoden
Erbt Methoden von seinem Elternteil, Event
.
ExtendableEvent.waitUntil()
-
Verlängert die Lebensdauer des Ereignisses. Es soll im
install
Ereignishandler für deninstalling
Worker und imactivate
Ereignishandler für denactive
Worker aufgerufen werden.
Beispiele
Dieses Codebeispiel stammt aus dem Service Worker Prefetch Beispiel (siehe Prefetch Beispiel live.) Der Code ruft ExtendableEvent.waitUntil()
in oninstall
auf und verzögert die Behandlung des ServiceWorkerRegistration.installing
Workers als installiert, bis das übergebene Versprechen erfolgreich aufgelöst wird. Das Versprechen wird aufgelöst, wenn alle Ressourcen abgerufen und im Cache gespeichert wurden oder wenn eine Ausnahme auftritt.
Der Code zeigt auch eine bewährte Methode zur Versionsverwaltung von Caches, die vom Service Worker verwendet werden. Obwohl es in diesem Beispiel nur einen Cache gibt, kann derselbe Ansatz für mehrere Caches verwendet werden. Es ordnet eine Kurzbezeichnung für einen Cache einem bestimmten, versionierten Cache-Namen zu.
Hinweis: In Chrome sind Protokollierungsaussagen über die "Inspect"-Schnittstelle für den relevanten Service Worker zugänglich unter chrome://serviceworker-internals sichtbar.
const CACHE_VERSION = 1;
const CURRENT_CACHES = {
prefetch: `prefetch-cache-v${CACHE_VERSION}`,
};
self.addEventListener("install", (event) => {
const urlsToPrefetch = [
"./static/pre_fetched.txt",
"./static/pre_fetched.html",
"https://www.chromium.org/_/rsrc/1302286216006/config/customLogo.gif",
];
console.log(
"Handling install event. Resources to pre-fetch:",
urlsToPrefetch,
);
event.waitUntil(
caches
.open(CURRENT_CACHES["prefetch"])
.then((cache) => {
return cache
.addAll(
urlsToPrefetch.map((urlToPrefetch) => {
return new Request(urlToPrefetch, { mode: "no-cors" });
}),
)
.then(() => {
console.log("All resources have been fetched and cached.");
});
})
.catch((error) => {
console.error("Pre-fetching failed:", error);
}),
);
});
Hinweis: Beim Abrufen von Ressourcen ist es sehr wichtig, {mode: 'no-cors'}
zu verwenden, wenn die Möglichkeit besteht, dass die Ressourcen von einem Server bereitgestellt werden, der CORS nicht unterstützt. In diesem Beispiel unterstützt www.chromium.org kein CORS.
Spezifikationen
Specification |
---|
Service Workers # extendableevent-interface |
Browser-Kompatibilität
BCD tables only load in the browser