Workbox-Strategien

Als Service Worker eingeführt wurden, entstand eine Reihe gängiger Caching-Strategien. Eine Caching-Strategie ist ein Muster, das bestimmt, wie ein Service Worker eine Antwort generiert, nachdem er ein Fetch-Ereignis empfangen hat.

workbox-strategies bietet die gängigsten Caching-Strategien, sodass Sie sie ganz einfach in Ihrem Service Worker anwenden können.

Wir gehen nicht auf Strategien ein, die nicht von Workbox unterstützt werden. Weitere Informationen finden Sie im Offline-Kochbuch.

Strategien verwenden

In den folgenden Beispielen wird gezeigt, wie Sie die Workbox-Caching-Strategien mit workbox-routing verwenden. Für jede Strategie können Sie einige Optionen definieren, die im Abschnitt „Strategien konfigurieren“ dieses Dokuments beschrieben werden.

Im Abschnitt zur erweiterten Nutzung wird beschrieben, wie Sie die Caching-Strategien direkt ohne workbox-routing verwenden können.

Stale-While-Revalidate

Diagramm „Veraltet während erneuter Validierung“

Mit dem Muster stale-while-revalidate können Sie so schnell wie möglich mit einer im Cache gespeicherten Antwort auf die Anfrage reagieren, sofern eine solche verfügbar ist. Andernfalls wird auf die Netzwerkanfrage zurückgegriffen. Die Netzwerkanfrage wird dann verwendet, um den Cache zu aktualisieren. Im Gegensatz zu einigen Implementierungen von „stale-while-revalidate“ wird bei dieser Strategie immer eine Revalidierungsanfrage gesendet, unabhängig vom Alter der im Cache gespeicherten Antwort.

Dies ist eine recht gängige Strategie, bei der die aktuellste Ressource für die Anwendung nicht unbedingt erforderlich ist.

import {registerRoute} from 'workbox-routing';
import {StaleWhileRevalidate} from 'workbox-strategies';

registerRoute(
  ({url}) => url.pathname.startsWith('/images/avatars/'),
  new StaleWhileRevalidate()
);

Cache First (Cache wird auf Netzwerk zurückgesetzt)

Erstes Diagramm im Cache speichern

Offline-Web-Apps sind stark vom Cache abhängig. Für nicht kritische Assets, die nach und nach im Cache gespeichert werden können, ist die Strategie Cache First die beste Option.

Wenn sich eine Antwort im Cache befindet, wird die Anfrage mit der Antwort aus dem Cache erfüllt und das Netzwerk wird überhaupt nicht verwendet. Wenn keine im Cache gespeicherte Antwort vorhanden ist, wird die Anfrage durch eine Netzwerkanfrage erfüllt und die Antwort wird im Cache gespeichert, sodass die nächste Anfrage direkt aus dem Cache beantwortet wird.

import {registerRoute} from 'workbox-routing';
import {CacheFirst} from 'workbox-strategies';

registerRoute(({request}) => request.destination === 'style', new CacheFirst());

Network First (Netzwerk mit Fallback auf Cache)

Network First-Diagramm

Für Anfragen, die häufig aktualisiert werden, ist die Strategie Network First die ideale Lösung. Standardmäßig wird versucht, die letzte Antwort aus dem Netzwerk abzurufen. Wenn die Anfrage erfolgreich ist, wird die Antwort im Cache gespeichert. Wenn das Netzwerk keine Antwort zurückgibt, wird die im Cache gespeicherte Antwort verwendet.

import {registerRoute} from 'workbox-routing';
import {NetworkFirst} from 'workbox-strategies';

registerRoute(
  ({url}) => url.pathname.startsWith('/social-timeline/'),
  new NetworkFirst()
);

Nur Netzwerk

Nur Netzwerkdiagramm

Wenn bestimmte Anfragen über das Netzwerk ausgeführt werden müssen, ist die Strategie Nur Netzwerk die richtige.

import {registerRoute} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';

registerRoute(({url}) => url.pathname.startsWith('/admin/'), new NetworkOnly());

Nur Cache

Nur Diagramm im Cache speichern

Die Strategie Nur Cache sorgt dafür, dass Antworten aus einem Cache abgerufen werden. Das ist in Workbox weniger üblich, kann aber nützlich sein, wenn Sie einen eigenen Schritt zum Vorab-Caching haben.

import {registerRoute} from 'workbox-routing';
import {CacheOnly} from 'workbox-strategies';

registerRoute(({url}) => url.pathname.startsWith('/app/v2/'), new CacheOnly());

Strategien konfigurieren

Bei allen Strategien können Sie Folgendes konfigurieren:

  • Der Name des Caches, der in der Strategie verwendet werden soll.
  • Einschränkungen für den Cache-Ablauf, die in der Strategie verwendet werden sollen.
  • Ein Array von Plug-ins, deren Lifecycle-Methoden beim Abrufen und Zwischenspeichern einer Anfrage aufgerufen werden.

Von einer Strategie verwendeten Cache ändern

Sie können den Cache ändern, der von einer Strategie verwendet wird, indem Sie einen Cache-Namen angeben. Das ist hilfreich, wenn Sie Ihre Assets zur Fehlersuche trennen möchten.

import {registerRoute} from 'workbox-routing';
import {CacheFirst} from 'workbox-strategies';

registerRoute(
  ({request}) => request.destination === 'image',
  new CacheFirst({
    cacheName: 'image-cache',
  })
);

Plug-ins verwenden

Workbox enthält eine Reihe von Plug-ins, die mit diesen Strategien verwendet werden können.

Wenn Sie eines dieser Plug-ins (oder ein benutzerdefiniertes Plug-in) verwenden möchten, müssen Sie nur Instanzen an die Option plugins übergeben.

import {registerRoute} from 'workbox-routing';
import {CacheFirst} from 'workbox-strategies';
import {ExpirationPlugin} from 'workbox-expiration';

registerRoute(
  ({request}) => request.destination === 'image',
  new CacheFirst({
    cacheName: 'image-cache',
    plugins: [
      new ExpirationPlugin({
        // Only cache requests for a week
        maxAgeSeconds: 7 * 24 * 60 * 60,
        // Only cache 10 requests.
        maxEntries: 10,
      }),
    ],
  })
);

Benutzerdefinierte Strategien

Neben der Konfiguration von Strategien können Sie mit Workbox auch eigene benutzerdefinierte Strategien erstellen. Dazu können Sie die Basisklasse Strategy aus workbox-strategies importieren und erweitern:

import {Strategy} from 'workbox-strategies';

class NewStrategy extends Strategy {
  _handle(request, handler) {
    // Define handling logic here
  }
}

In diesem Beispiel wird handle() als Anfragestrategie verwendet, um eine bestimmte Verarbeitungslogik zu definieren. Es gibt zwei Anfragestrategien, die verwendet werden können:

  • handle(): Führt eine Anfragestrategie aus und gibt ein Promise zurück, das mit einem Response aufgelöst wird. Dabei werden alle relevanten Plugin-Callbacks aufgerufen.
  • handleAll(): Ähnlich wie handle(), gibt aber zwei Promise-Objekte zurück. Die erste entspricht dem, was handle() zurückgibt, und die zweite wird aufgelöst, wenn die Promises, die event.waitUntil() innerhalb der Strategie hinzugefügt wurden, abgeschlossen sind.

Beide Anfragestrategien werden mit zwei Parametern aufgerufen:

  • request: Die Request, für die die Strategie eine Antwort zurückgibt.
  • handler: Eine StrategyHandler-Instanz, die automatisch für die aktuelle Strategie erstellt wurde.

Neue Strategie erstellen

Im Folgenden finden Sie ein Beispiel für eine neue Strategie, die das Verhalten von NetworkOnly neu implementiert:

class NewNetworkOnlyStrategy extends Strategy {
  _handle(request, handler) {
    return handler.fetch(request);
  }
}

Beachten Sie, dass handler.fetch() anstelle der nativen Methode fetch aufgerufen wird. Die Klasse StrategyHandler bietet eine Reihe von Abruf- und Cache-Aktionen, die immer dann verwendet werden können, wenn handle() oder handleAll() verwendet wird:

  • fetch: Ruft eine bestimmte Anfrage ab und ruft die Plugin-Lebenszyklusmethoden requestWillFetch(), fetchDidSucceed() und fetchDidFail() auf.
  • cacheMatch: Entspricht einer Anfrage aus dem Cache und ruft die Plugin-Lebenszyklusmethoden cacheKeyWillBeUsed() und cachedResponseWillBeUsed() auf.
  • cachePut: Legt ein Anfrage-/Antwortpaar im Cache ab und ruft die Plugin-Lifecycle-Methoden cacheKeyWillBeUsed(), cacheWillUpdate() und cacheDidUpdate() auf.
  • fetchAndCachePut: Ruft fetch() auf und führt cachePut() im Hintergrund für die von fetch() generierte Antwort aus.
  • hasCallback: Nimmt einen Callback als Eingabe entgegen und gibt „true“ zurück, wenn die Strategie mindestens ein Plug-in mit dem angegebenen Callback hat.
  • runCallbacks: Führt alle Plugin-Callbacks mit einem bestimmten Namen in der angegebenen Reihenfolge aus und übergibt ein bestimmtes Parameterobjekt (das mit dem aktuellen Plugin-Status zusammengeführt wurde) als einziges Argument.
  • iterateCallbacks: Akzeptiert einen Callback und gibt ein Iterable mit übereinstimmenden Plugin-Callbacks zurück.Jeder Callback wird mit dem aktuellen Handler-Status umschlossen. Wenn Sie also einen Callback aufrufen, wird jeder Objektparameter, den Sie übergeben, mit dem aktuellen Status des Plugins zusammengeführt.
  • waitUntil: Fügt den Versprechen zur Verlängerung der Lebensdauer des Ereignisses, das mit der bearbeiteten Anfrage verknüpft ist (in der Regel ein FetchEvent), ein Promise hinzu.
  • doneWaiting: Gibt ein Promise zurück, das aufgelöst wird, sobald alle an waitUntil() übergebenen Promises abgeschlossen sind.
  • destroy: Die Strategie wird nicht mehr ausgeführt und alle ausstehenden waitUntil()-Versprechen werden sofort erfüllt.

Benutzerdefinierte Cache-Netzwerk-Race-Strategie

Das folgende Beispiel basiert auf cache-network-race aus dem Offline Cookbook (das nicht von Workbox bereitgestellt wird), geht aber noch einen Schritt weiter und aktualisiert den Cache immer nach einer erfolgreichen Netzwerkanfrage. Dies ist ein Beispiel für eine komplexere Strategie, bei der mehrere Aktionen verwendet werden.

import {Strategy} from 'workbox-strategies';

class CacheNetworkRace extends Strategy {
  _handle(request, handler) {
    const fetchAndCachePutDone = handler.fetchAndCachePut(request);
    const cacheMatchDone = handler.cacheMatch(request);

    return new Promise((resolve, reject) => {
      fetchAndCachePutDone.then(resolve);
      cacheMatchDone.then(response => response && resolve(response));

      // Reject if both network and cache error or find no response.
      Promise.allSettled([fetchAndCachePutDone, cacheMatchDone]).then(
        results => {
          const [fetchAndCachePutResult, cacheMatchResult] = results;
          if (
            fetchAndCachePutResult.status === 'rejected' &&
            !cacheMatchResult.value
          ) {
            reject(fetchAndCachePutResult.reason);
          }
        }
      );
    });
  }
}

Erweiterte Nutzung

Wenn Sie die Strategien in Ihrer eigenen Fetch-Ereignislogik verwenden möchten, können Sie die Strategieklassen nutzen, um eine Anfrage über eine bestimmte Strategie auszuführen.

Wenn Sie beispielsweise die Strategie „stale-while-revalidate“ verwenden möchten, können Sie Folgendes tun:

self.addEventListener('fetch', event => {
  const {request} = event;
  const url = new URL(request.url);

  if (url.origin === location.origin && url.pathname === '/') {
    event.respondWith(new StaleWhileRevalidate().handle({event, request}));
  }
});

Eine Liste der verfügbaren Klassen finden Sie in der Workbox-Strategien-Referenzdokumentation.

Typen

CacheFirst

Eine Implementierung einer Cache-First-Anfragestrategie.

Eine Cache-First-Strategie ist nützlich für Assets, die überarbeitet wurden, z. B. URLs wie /styles/example.a8f5f1.css, da sie für lange Zeit im Cache gespeichert werden können.

Wenn die Netzwerkanfrage fehlschlägt und es keine Cache-Übereinstimmung gibt, wird eine WorkboxError-Ausnahme ausgelöst.

Attribute

  • Konstruktor

    void

    Erstellt eine neue Instanz der Strategie und legt alle dokumentierten Optionsattribute als öffentliche Instanzattribute fest.

    Hinweis: Wenn eine benutzerdefinierte Strategieklasse die Basisklasse „Strategy“ erweitert und nicht mehr als diese Attribute benötigt, muss sie keinen eigenen Konstruktor definieren.

    Die constructor-Funktion sieht so aus:

    (options?: StrategyOptions) => {...}

  • cacheName

    String

  • fetchOptions

    RequestInit optional

  • matchOptions

    CacheQueryOptions optional

  • Plug-ins
  • _awaitComplete

    void

    Die _awaitComplete-Funktion sieht so aus:

    (responseDone: Promise<Response>, handler: StrategyHandler, request: Request, event: ExtendableEvent) => {...}

    • responseDone

      Promise<Response>

    • Handler
    • Anfrage

      Anfrage

    • event

      ExtendableEvent

    • Gibt zurück

      Promise<void>

  • _getResponse

    void

    Die _getResponse-Funktion sieht so aus:

    (handler: StrategyHandler, request: Request, event: ExtendableEvent) => {...}

    • Gibt zurück

      Promise<Response>

  • Handle (der)

    void

    Führt eine Anfragestrategie aus und gibt ein Promise zurück, das mit einem Response aufgelöst wird, wobei alle relevanten Plug-in-Callbacks aufgerufen werden.

    Wenn eine Strategieinstanz in einem Workbox-workbox-routing.Route registriert ist, wird diese Methode automatisch aufgerufen, wenn die Route übereinstimmt.

    Alternativ kann diese Methode in einem eigenständigen FetchEvent-Listener verwendet werden, indem sie an event.respondWith() übergeben wird.

    Die handle-Funktion sieht so aus:

    (options: FetchEvent | HandlerCallbackOptions) => {...}

    • Optionen

      FetchEvent | HandlerCallbackOptions

      Ein FetchEvent oder ein Objekt mit den unten aufgeführten Attributen.

    • Gibt zurück

      Promise<Response>

  • handleAll

    void

    Ähnlich wie workbox-strategies.Strategy~handle, aber anstatt nur ein Promise zurückzugeben, das in ein Response aufgelöst wird, wird ein Tupel von [response, done]-Promises zurückgegeben. Das erste (response) entspricht dem, was handle() zurückgibt, und das zweite ist ein Promise, das aufgelöst wird, sobald alle Promises, die event.waitUntil() im Rahmen der Strategie hinzugefügt wurden, abgeschlossen sind.

    Sie können auf das done-Promise warten, um sicherzustellen, dass alle zusätzlichen Aufgaben, die von der Strategie ausgeführt werden (in der Regel das Speichern von Antworten im Cache), erfolgreich abgeschlossen werden.

    Die handleAll-Funktion sieht so aus:

    (options: FetchEvent | HandlerCallbackOptions) => {...}

    • Optionen

      FetchEvent | HandlerCallbackOptions

      Ein FetchEvent oder ein Objekt mit den unten aufgeführten Attributen.

    • Gibt zurück

      [Promise<Response>, Promise<void>]

      Ein Tupel aus [response, done]-Promises, mit dem bestimmt werden kann, wann die Antwort aufgelöst wird und wann der Handler seine Arbeit abgeschlossen hat.

CacheOnly

Eine Implementierung einer cache-only-Anfragestrategie.

Diese Klasse ist nützlich, wenn Sie Workbox-Plug-ins verwenden möchten.

Wenn keine Cache-Übereinstimmung gefunden wird, wird eine WorkboxError-Ausnahme ausgelöst.

Attribute

  • Konstruktor

    void

    Erstellt eine neue Instanz der Strategie und legt alle dokumentierten Optionsattribute als öffentliche Instanzattribute fest.

    Hinweis: Wenn eine benutzerdefinierte Strategieklasse die Basisklasse „Strategy“ erweitert und nicht mehr als diese Attribute benötigt, muss sie keinen eigenen Konstruktor definieren.

    Die constructor-Funktion sieht so aus:

    (options?: StrategyOptions) => {...}

  • cacheName

    String

  • fetchOptions

    RequestInit optional

  • matchOptions

    CacheQueryOptions optional

  • Plug-ins
  • _awaitComplete

    void

    Die _awaitComplete-Funktion sieht so aus:

    (responseDone: Promise<Response>, handler: StrategyHandler, request: Request, event: ExtendableEvent) => {...}

    • responseDone

      Promise<Response>

    • Handler
    • Anfrage

      Anfrage

    • event

      ExtendableEvent

    • Gibt zurück

      Promise<void>

  • _getResponse

    void

    Die _getResponse-Funktion sieht so aus:

    (handler: StrategyHandler, request: Request, event: ExtendableEvent) => {...}

    • Gibt zurück

      Promise<Response>

  • Handle (der)

    void

    Führt eine Anfragestrategie aus und gibt ein Promise zurück, das mit einem Response aufgelöst wird, wobei alle relevanten Plug-in-Callbacks aufgerufen werden.

    Wenn eine Strategieinstanz in einem Workbox-workbox-routing.Route registriert ist, wird diese Methode automatisch aufgerufen, wenn die Route übereinstimmt.

    Alternativ kann diese Methode in einem eigenständigen FetchEvent-Listener verwendet werden, indem sie an event.respondWith() übergeben wird.

    Die handle-Funktion sieht so aus:

    (options: FetchEvent | HandlerCallbackOptions) => {...}

    • Optionen

      FetchEvent | HandlerCallbackOptions

      Ein FetchEvent oder ein Objekt mit den unten aufgeführten Attributen.

    • Gibt zurück

      Promise<Response>

  • handleAll

    void

    Ähnlich wie workbox-strategies.Strategy~handle, aber anstatt nur ein Promise zurückzugeben, das in ein Response aufgelöst wird, wird ein Tupel von [response, done]-Promises zurückgegeben. Das erste (response) entspricht dem, was handle() zurückgibt, und das zweite ist ein Promise, das aufgelöst wird, sobald alle Promises, die event.waitUntil() im Rahmen der Strategie hinzugefügt wurden, abgeschlossen sind.

    Sie können auf das done-Promise warten, um sicherzustellen, dass alle zusätzlichen Aufgaben, die von der Strategie ausgeführt werden (in der Regel das Speichern von Antworten im Cache), erfolgreich abgeschlossen werden.

    Die handleAll-Funktion sieht so aus:

    (options: FetchEvent | HandlerCallbackOptions) => {...}

    • Optionen

      FetchEvent | HandlerCallbackOptions

      Ein FetchEvent oder ein Objekt mit den unten aufgeführten Attributen.

    • Gibt zurück

      [Promise<Response>, Promise<void>]

      Ein Tupel aus [response, done]-Promises, mit dem bestimmt werden kann, wann die Antwort aufgelöst wird und wann der Handler seine Arbeit abgeschlossen hat.

NetworkFirst

Eine Implementierung einer Network-First-Anfragestrategie.

Standardmäßig werden bei dieser Strategie Antworten mit dem Statuscode 200 sowie undurchsichtige Antworten im Cache gespeichert. Undurchsichtige Antworten sind Cross-Origin-Anfragen, bei denen die Antwort CORS nicht unterstützt.

Wenn die Netzwerkanfrage fehlschlägt und es keine Cache-Übereinstimmung gibt, wird eine WorkboxError-Ausnahme ausgelöst.

Attribute

  • Konstruktor

    void

    Die constructor-Funktion sieht so aus:

    (options?: NetworkFirstOptions) => {...}

  • cacheName

    String

  • fetchOptions

    RequestInit optional

  • matchOptions

    CacheQueryOptions optional

  • Plug-ins
  • _awaitComplete

    void

    Die _awaitComplete-Funktion sieht so aus:

    (responseDone: Promise<Response>, handler: StrategyHandler, request: Request, event: ExtendableEvent) => {...}

    • responseDone

      Promise<Response>

    • Handler
    • Anfrage

      Anfrage

    • event

      ExtendableEvent

    • Gibt zurück

      Promise<void>

  • _getResponse

    void

    Die _getResponse-Funktion sieht so aus:

    (handler: StrategyHandler, request: Request, event: ExtendableEvent) => {...}

    • Gibt zurück

      Promise<Response>

  • Handle (der)

    void

    Führt eine Anfragestrategie aus und gibt ein Promise zurück, das mit einem Response aufgelöst wird, wobei alle relevanten Plug-in-Callbacks aufgerufen werden.

    Wenn eine Strategieinstanz in einem Workbox-workbox-routing.Route registriert ist, wird diese Methode automatisch aufgerufen, wenn die Route übereinstimmt.

    Alternativ kann diese Methode in einem eigenständigen FetchEvent-Listener verwendet werden, indem sie an event.respondWith() übergeben wird.

    Die handle-Funktion sieht so aus:

    (options: FetchEvent | HandlerCallbackOptions) => {...}

    • Optionen

      FetchEvent | HandlerCallbackOptions

      Ein FetchEvent oder ein Objekt mit den unten aufgeführten Attributen.

    • Gibt zurück

      Promise<Response>

  • handleAll

    void

    Ähnlich wie workbox-strategies.Strategy~handle, aber anstatt nur ein Promise zurückzugeben, das in ein Response aufgelöst wird, wird ein Tupel von [response, done]-Promises zurückgegeben. Das erste (response) entspricht dem, was handle() zurückgibt, und das zweite ist ein Promise, das aufgelöst wird, sobald alle Promises, die event.waitUntil() im Rahmen der Strategie hinzugefügt wurden, abgeschlossen sind.

    Sie können auf das done-Promise warten, um sicherzustellen, dass alle zusätzlichen Aufgaben, die von der Strategie ausgeführt werden (in der Regel das Speichern von Antworten im Cache), erfolgreich abgeschlossen werden.

    Die handleAll-Funktion sieht so aus:

    (options: FetchEvent | HandlerCallbackOptions) => {...}

    • Optionen

      FetchEvent | HandlerCallbackOptions

      Ein FetchEvent oder ein Objekt mit den unten aufgeführten Attributen.

    • Gibt zurück

      [Promise<Response>, Promise<void>]

      Ein Tupel aus [response, done]-Promises, mit dem bestimmt werden kann, wann die Antwort aufgelöst wird und wann der Handler seine Arbeit abgeschlossen hat.

NetworkFirstOptions

Attribute

  • cacheName

    String optional

  • fetchOptions

    RequestInit optional

  • matchOptions

    CacheQueryOptions optional

  • networkTimeoutSeconds

    number optional

  • Plug-ins

    WorkboxPlugin[] optional

NetworkOnly

Eine Implementierung einer Nur Netzwerk-Anfragestrategie.

Diese Klasse ist nützlich, wenn Sie Workbox-Plug-ins verwenden möchten.

Wenn die Netzwerkanfrage fehlschlägt, wird eine WorkboxError-Ausnahme ausgelöst.

Attribute

  • Konstruktor

    void

    Die constructor-Funktion sieht so aus:

    (options?: NetworkOnlyOptions) => {...}

  • cacheName

    String

  • fetchOptions

    RequestInit optional

  • matchOptions

    CacheQueryOptions optional

  • Plug-ins
  • _awaitComplete

    void

    Die _awaitComplete-Funktion sieht so aus:

    (responseDone: Promise<Response>, handler: StrategyHandler, request: Request, event: ExtendableEvent) => {...}

    • responseDone

      Promise<Response>

    • Handler
    • Anfrage

      Anfrage

    • event

      ExtendableEvent

    • Gibt zurück

      Promise<void>

  • _getResponse

    void

    Die _getResponse-Funktion sieht so aus:

    (handler: StrategyHandler, request: Request, event: ExtendableEvent) => {...}

    • Gibt zurück

      Promise<Response>

  • Handle (der)

    void

    Führt eine Anfragestrategie aus und gibt ein Promise zurück, das mit einem Response aufgelöst wird, wobei alle relevanten Plug-in-Callbacks aufgerufen werden.

    Wenn eine Strategieinstanz in einem Workbox-workbox-routing.Route registriert ist, wird diese Methode automatisch aufgerufen, wenn die Route übereinstimmt.

    Alternativ kann diese Methode in einem eigenständigen FetchEvent-Listener verwendet werden, indem sie an event.respondWith() übergeben wird.

    Die handle-Funktion sieht so aus:

    (options: FetchEvent | HandlerCallbackOptions) => {...}

    • Optionen

      FetchEvent | HandlerCallbackOptions

      Ein FetchEvent oder ein Objekt mit den unten aufgeführten Attributen.

    • Gibt zurück

      Promise<Response>

  • handleAll

    void

    Ähnlich wie workbox-strategies.Strategy~handle, aber anstatt nur ein Promise zurückzugeben, das in ein Response aufgelöst wird, wird ein Tupel von [response, done]-Promises zurückgegeben. Das erste (response) entspricht dem, was handle() zurückgibt, und das zweite ist ein Promise, das aufgelöst wird, sobald alle Promises, die event.waitUntil() im Rahmen der Strategie hinzugefügt wurden, abgeschlossen sind.

    Sie können auf das done-Promise warten, um sicherzustellen, dass alle zusätzlichen Aufgaben, die von der Strategie ausgeführt werden (in der Regel das Speichern von Antworten im Cache), erfolgreich abgeschlossen werden.

    Die handleAll-Funktion sieht so aus:

    (options: FetchEvent | HandlerCallbackOptions) => {...}

    • Optionen

      FetchEvent | HandlerCallbackOptions

      Ein FetchEvent oder ein Objekt mit den unten aufgeführten Attributen.

    • Gibt zurück

      [Promise<Response>, Promise<void>]

      Ein Tupel aus [response, done]-Promises, mit dem bestimmt werden kann, wann die Antwort aufgelöst wird und wann der Handler seine Arbeit abgeschlossen hat.

NetworkOnlyOptions

Attribute

  • fetchOptions

    RequestInit optional

  • networkTimeoutSeconds

    number optional

  • Plug-ins

    WorkboxPlugin[] optional

StaleWhileRevalidate

Eine Implementierung der Anfragestrategie Stale-while-revalidate.

Ressourcen werden parallel sowohl aus dem Cache als auch aus dem Netzwerk angefordert. Die Strategie reagiert mit der im Cache gespeicherten Version, sofern verfügbar. Andernfalls wird auf die Netzwerkantwort gewartet. Der Cache wird bei jeder erfolgreichen Anfrage mit der Netzwerkantwort aktualisiert.

Standardmäßig werden bei dieser Strategie Antworten mit dem Statuscode 200 sowie undurchsichtige Antworten im Cache gespeichert. Undurchsichtige Antworten sind anfrageübergreifende Anfragen, bei denen die Antwort CORS nicht unterstützt.

Wenn die Netzwerkanfrage fehlschlägt und es keine Cache-Übereinstimmung gibt, wird eine WorkboxError-Ausnahme ausgelöst.

Attribute

  • Konstruktor

    void

    Die constructor-Funktion sieht so aus:

    (options?: StrategyOptions) => {...}

  • cacheName

    String

  • fetchOptions

    RequestInit optional

  • matchOptions

    CacheQueryOptions optional

  • Plug-ins
  • _awaitComplete

    void

    Die _awaitComplete-Funktion sieht so aus:

    (responseDone: Promise<Response>, handler: StrategyHandler, request: Request, event: ExtendableEvent) => {...}

    • responseDone

      Promise<Response>

    • Handler
    • Anfrage

      Anfrage

    • event

      ExtendableEvent

    • Gibt zurück

      Promise<void>

  • _getResponse

    void

    Die _getResponse-Funktion sieht so aus:

    (handler: StrategyHandler, request: Request, event: ExtendableEvent) => {...}

    • Gibt zurück

      Promise<Response>

  • Handle (der)

    void

    Führt eine Anfragestrategie aus und gibt ein Promise zurück, das mit einem Response aufgelöst wird, wobei alle relevanten Plug-in-Callbacks aufgerufen werden.

    Wenn eine Strategieinstanz in einem Workbox-workbox-routing.Route registriert ist, wird diese Methode automatisch aufgerufen, wenn die Route übereinstimmt.

    Alternativ kann diese Methode in einem eigenständigen FetchEvent-Listener verwendet werden, indem sie an event.respondWith() übergeben wird.

    Die handle-Funktion sieht so aus:

    (options: FetchEvent | HandlerCallbackOptions) => {...}

    • Optionen

      FetchEvent | HandlerCallbackOptions

      Ein FetchEvent oder ein Objekt mit den unten aufgeführten Attributen.

    • Gibt zurück

      Promise<Response>

  • handleAll

    void

    Ähnlich wie workbox-strategies.Strategy~handle, aber anstatt nur ein Promise zurückzugeben, das in ein Response aufgelöst wird, wird ein Tupel von [response, done]-Promises zurückgegeben. Das erste (response) entspricht dem, was handle() zurückgibt, und das zweite ist ein Promise, das aufgelöst wird, sobald alle Promises, die event.waitUntil() im Rahmen der Strategie hinzugefügt wurden, abgeschlossen sind.

    Sie können auf das done-Promise warten, um sicherzustellen, dass alle zusätzlichen Aufgaben, die von der Strategie ausgeführt werden (in der Regel das Speichern von Antworten im Cache), erfolgreich abgeschlossen werden.

    Die handleAll-Funktion sieht so aus:

    (options: FetchEvent | HandlerCallbackOptions) => {...}

    • Optionen

      FetchEvent | HandlerCallbackOptions

      Ein FetchEvent oder ein Objekt mit den unten aufgeführten Attributen.

    • Gibt zurück

      [Promise<Response>, Promise<void>]

      Ein Tupel aus [response, done]-Promises, mit dem bestimmt werden kann, wann die Antwort aufgelöst wird und wann der Handler seine Arbeit abgeschlossen hat.

Strategy

Eine abstrakte Basisklasse, von der alle anderen Strategieklassen abgeleitet werden müssen:

Attribute

  • Konstruktor

    void

    Erstellt eine neue Instanz der Strategie und legt alle dokumentierten Optionsattribute als öffentliche Instanzattribute fest.

    Hinweis: Wenn eine benutzerdefinierte Strategieklasse die Basisklasse „Strategy“ erweitert und nicht mehr als diese Attribute benötigt, muss sie keinen eigenen Konstruktor definieren.

    Die constructor-Funktion sieht so aus:

    (options?: StrategyOptions) => {...}

  • cacheName

    String

  • fetchOptions

    RequestInit optional

  • matchOptions

    CacheQueryOptions optional

  • Plug-ins
  • _awaitComplete

    void

    Die _awaitComplete-Funktion sieht so aus:

    (responseDone: Promise<Response>, handler: StrategyHandler, request: Request, event: ExtendableEvent) => {...}

    • responseDone

      Promise<Response>

    • Handler
    • Anfrage

      Anfrage

    • event

      ExtendableEvent

    • Gibt zurück

      Promise<void>

  • _getResponse

    void

    Die _getResponse-Funktion sieht so aus:

    (handler: StrategyHandler, request: Request, event: ExtendableEvent) => {...}

    • Gibt zurück

      Promise<Response>

  • _handle

    void

    Die _handle-Funktion sieht so aus:

    (request: Request, handler: StrategyHandler) => {...}

    • Gibt zurück

      Promise<Response>

  • Handle (der)

    void

    Führt eine Anfragestrategie aus und gibt ein Promise zurück, das mit einem Response aufgelöst wird, wobei alle relevanten Plug-in-Callbacks aufgerufen werden.

    Wenn eine Strategieinstanz in einem Workbox-workbox-routing.Route registriert ist, wird diese Methode automatisch aufgerufen, wenn die Route übereinstimmt.

    Alternativ kann diese Methode in einem eigenständigen FetchEvent-Listener verwendet werden, indem sie an event.respondWith() übergeben wird.

    Die handle-Funktion sieht so aus:

    (options: FetchEvent | HandlerCallbackOptions) => {...}

    • Optionen

      FetchEvent | HandlerCallbackOptions

      Ein FetchEvent oder ein Objekt mit den unten aufgeführten Attributen.

    • Gibt zurück

      Promise<Response>

  • handleAll

    void

    Ähnlich wie workbox-strategies.Strategy~handle, aber anstatt nur ein Promise zurückzugeben, das in ein Response aufgelöst wird, wird ein Tupel von [response, done]-Promises zurückgegeben. Das erste (response) entspricht dem, was handle() zurückgibt, und das zweite ist ein Promise, das aufgelöst wird, sobald alle Promises, die event.waitUntil() im Rahmen der Strategie hinzugefügt wurden, abgeschlossen sind.

    Sie können auf das done-Promise warten, um sicherzustellen, dass alle zusätzlichen Aufgaben, die von der Strategie ausgeführt werden (in der Regel das Speichern von Antworten im Cache), erfolgreich abgeschlossen werden.

    Die handleAll-Funktion sieht so aus:

    (options: FetchEvent | HandlerCallbackOptions) => {...}

    • Optionen

      FetchEvent | HandlerCallbackOptions

      Ein FetchEvent oder ein Objekt mit den unten aufgeführten Attributen.

    • Gibt zurück

      [Promise<Response>, Promise<void>]

      Ein Tupel aus [response, done]-Promises, mit dem bestimmt werden kann, wann die Antwort aufgelöst wird und wann der Handler seine Arbeit abgeschlossen hat.

StrategyHandler

Eine Klasse, die jedes Mal erstellt wird, wenn eine Strategy-Instanz workbox-strategies.Strategy~handle oder workbox-strategies.Strategy~handleAll aufruft. Sie umschließt alle Abruf- und Cachevorgänge mit Plugin-Callbacks und verfolgt, wann die Strategie „fertig“ ist (d. h. alle hinzugefügten event.waitUntil()-Promises wurden aufgelöst).

Attribute

  • Konstruktor

    void

    Erstellt eine neue Instanz, die der übergebenen Strategie und dem Ereignis zugeordnet ist, das die Anfrage verarbeitet.

    Der Konstruktor initialisiert auch den Status, der an jedes der Plugins übergeben wird, die diese Anfrage verarbeiten.

    Die constructor-Funktion sieht so aus:

    (strategy: Strategy, options: HandlerCallbackOptions) => {...}

  • event

    ExtendableEvent

  • params

    beliebig optional

  • Anfrage

    Anfrage

  • URL

    URL optional

  • cacheMatch

    void

    Entspricht einer Anfrage aus dem Cache (und ruft alle anwendbaren Plugin-Callback-Methoden auf) unter Verwendung von cacheName, matchOptions und plugins, die für das Strategieobjekt definiert sind.

    Die folgenden Methoden des Plugin-Lebenszyklus werden aufgerufen, wenn diese Methode verwendet wird:

    • cacheKeyWillBeUsed()
    • cachedResponseWillBeUsed()

    Die cacheMatch-Funktion sieht so aus:

    (key: RequestInfo) => {...}

    • Schlüssel

      RequestInfo

      Die Anfrage oder URL, die als Cache-Schlüssel verwendet werden soll.

    • Gibt zurück

      Promise<Response>

      Eine passende Antwort, falls gefunden.

  • cachePut

    void

    Legt ein Anfrage-/Antwortpaar mithilfe der im Strategieobjekt definierten cacheName und plugins im Cache ab und ruft alle anwendbaren Plugin-Callback-Methoden auf.

    Die folgenden Methoden des Plugin-Lebenszyklus werden aufgerufen, wenn diese Methode verwendet wird:

    • cacheKeyWillBeUsed()
    • cacheWillUpdate()
    • cacheDidUpdate()

    Die cachePut-Funktion sieht so aus:

    (key: RequestInfo, response: Response) => {...}

    • Schlüssel

      RequestInfo

      Die Anfrage oder URL, die als Cache-Schlüssel verwendet werden soll.

    • Antwort

      Antwort

      Die Antwort, die im Cache gespeichert werden soll.

    • Gibt zurück

      Promise<boolean>

      false, wenn eine cacheWillUpdate-Anweisung dazu geführt hat, dass die Antwort nicht im Cache gespeichert wurde, andernfalls true.

  • löschen

    void

    Die Ausführung der Strategie wird beendet und alle ausstehenden waitUntil()-Promises werden sofort aufgelöst.

    Die destroy-Funktion sieht so aus:

    () => {...}

  • doneWaiting

    void

    Gibt ein Promise zurück, das aufgelöst wird, sobald alle an workbox-strategies.StrategyHandler~waitUntil übergebenen Promises abgeschlossen sind.

    Hinweis: Alle Arbeiten, die nach dem Abschluss von doneWaiting() ausgeführt werden, sollten manuell an die waitUntil()-Methode eines Ereignisses übergeben werden (nicht an die waitUntil()-Methode dieses Handlers). Andernfalls wird der Service Worker-Thread möglicherweise beendet, bevor Ihre Arbeit abgeschlossen ist.

    Die doneWaiting-Funktion sieht so aus:

    () => {...}

    • Gibt zurück

      Promise<void>

  • abrufen

    void

    Ruft eine bestimmte Anfrage ab (und ruft alle anwendbaren Plugin-Callback-Methoden auf) und verwendet dabei fetchOptions (für Anfragen, die keine Navigationsanfragen sind) und plugins, die für das Strategy-Objekt definiert sind.

    Die folgenden Methoden des Plugin-Lebenszyklus werden aufgerufen, wenn diese Methode verwendet wird:

    • requestWillFetch()
    • fetchDidSucceed()
    • fetchDidFail()

    Die fetch-Funktion sieht so aus:

    (input: RequestInfo) => {...}

    • Eingabe

      RequestInfo

      Die URL oder Anfrage, die abgerufen werden soll.

    • Gibt zurück

      Promise<Response>

  • fetchAndCachePut

    void

    Ruft this.fetch() auf und führt (im Hintergrund) this.cachePut() für die von this.fetch() generierte Antwort aus.

    Durch den Aufruf von this.cachePut() wird automatisch this.waitUntil() aufgerufen. Sie müssen waitUntil() also nicht manuell für das Ereignis aufrufen.

    Die fetchAndCachePut-Funktion sieht so aus:

    (input: RequestInfo) => {...}

    • Eingabe

      RequestInfo

      Die Anfrage oder URL, die abgerufen und im Cache gespeichert werden soll.

    • Gibt zurück

      Promise<Response>

  • getCacheKey

    void

    Prüft die Liste der Plug-ins auf den cacheKeyWillBeUsed-Callback und führt alle gefundenen Callbacks nacheinander aus. Das endgültige Request-Objekt, das vom letzten Plug-in zurückgegeben wird, wird als Cache-Schlüssel für Cache-Lese- und/oder ‑Schreibvorgänge behandelt. Wenn keine cacheKeyWillBeUsed-Plug-in-Callbacks registriert wurden, wird die übergebene Anfrage unverändert zurückgegeben.

    Die getCacheKey-Funktion sieht so aus:

    (request: Request, mode: "read" 
     | "write"
    ) => {...}

    • Anfrage

      Anfrage

    • Modus

      „read“
       | „write“

    • Gibt zurück

      Promise<Request>

  • hasCallback

    void

    Gibt „true“ zurück, wenn die Strategie mindestens ein Plug-in mit dem angegebenen Callback hat.

    Die hasCallback-Funktion sieht so aus:

    (name: C) => {...}

    • name

      C

      Der Name des Callbacks, nach dem gesucht werden soll.

    • Gibt zurück

      boolean

  • iterateCallbacks

    void

    Akzeptiert einen Callback und gibt ein Iterable mit übereinstimmenden Plugin-Callbacks zurück, wobei jeder Callback mit dem aktuellen Handler-Status umschlossen wird. Wenn Sie also einen Callback aufrufen, wird jeder Objektparameter, den Sie ihm übergeben, mit dem aktuellen Status des Plugins zusammengeführt.

    Die iterateCallbacks-Funktion sieht so aus:

    (name: C) => {...}

    • name

      C

      Der Name des auszuführenden Rückrufs.

    • Gibt zurück

      Generator<NonNullable<indexedAccess>anyunknown>

  • runCallbacks

    void

    Führt alle Plug‑in-Callbacks aus, die dem angegebenen Namen entsprechen, und übergibt das angegebene Parameterobjekt (mit dem aktuellen Plug‑in-Status zusammengeführt) als einziges Argument.

    Hinweis: Da mit dieser Methode alle Plugins ausgeführt werden, ist sie nicht für Fälle geeignet, in denen der Rückgabewert eines Callbacks vor dem Aufrufen des nächsten Callbacks angewendet werden muss. Informationen dazu, wie du in diesem Fall vorgehen solltest, findest du unten im Abschnitt workbox-strategies.StrategyHandler#iterateCallbacks.

    Die runCallbacks-Funktion sieht so aus:

    (name: C, param: Omit<indexedAccess"state" 
    >) => {...}

    • name

      C

      Der Name des Callbacks, der in jedem Plug-in ausgeführt werden soll.

    • param

      Omit<indexedAccess"state"
      >

      Das Objekt, das als erster (und einziger) Parameter beim Ausführen der einzelnen Callbacks übergeben werden soll. Dieses Objekt wird vor der Ausführung des Callbacks mit dem aktuellen Plugin-Status zusammengeführt.

    • Gibt zurück

      Promise<void>

  • waitUntil

    void

    Fügt dem [extend lifetime promises]https://w3c.github.io/ServiceWorker/#extendableevent-extend-lifetime-promises des Ereignisses, das mit der bearbeiteten Anfrage verknüpft ist (in der Regel ein FetchEvent), ein Promise hinzu.

    Hinweis: Sie können workbox-strategies.StrategyHandler~doneWaiting abwarten, um zu erfahren, wann alle hinzugefügten Promises abgeschlossen sind.

    Die waitUntil-Funktion sieht so aus:

    (promise: Promise<T>) => {...}

    • Promise

      Promise<T>

      Ein Versprechen, das den Versprechen zur Verlängerung der Lebensdauer des Ereignisses hinzugefügt werden soll, das die Anfrage ausgelöst hat.

    • Gibt zurück

      Promise<T>

StrategyOptions

Attribute

  • cacheName

    String optional

  • fetchOptions

    RequestInit optional

  • matchOptions

    CacheQueryOptions optional

  • Plug-ins

    WorkboxPlugin[] optional