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.

Event ExtendableEvent

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 den installing Worker und im activate Ereignishandler für den active 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.

js
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

Siehe auch