Workbox-Strategien

Als Service Worker eingeführt wurden, haben sich einige gängige Caching-Strategien herauskristallisiert. Eine Caching-Strategie ist ein Muster, das bestimmt, wie ein Service Worker eine Antwort generiert, nachdem er ein Abrufereignis erhalten hat.

workbox-strategies bietet die gängigsten Caching-Strategien, die sich ganz einfach in Ihrem Service Worker anwenden lassen.

Wir gehen hier nicht weiter auf die von Workbox unterstützten Strategien ein. Weitere Informationen finden Sie jedoch im Offline-Kochbuch.

Strategien verwenden

In den folgenden Beispielen zeigen wir Ihnen, wie Sie die Workbox-Caching-Strategien mit workbox-routing verwenden. Für jede Strategie können Sie einige Optionen definieren. Weitere Informationen finden Sie im Abschnitt „Strategien konfigurieren“ dieses Dokuments.

Im Abschnitt Erweiterte Verwendung erfahren Sie, wie Sie die Caching-Strategien direkt ohne workbox-routing verwenden können.

Stale-While-Revalidate

Diagramm „Veraltete Inhalte bei nochmaliger Validierung“

Mit dem Muster stale-while-revalidate können Sie so schnell wie möglich mit einer im Cache gespeicherten Antwort auf die Anfrage antworten, sofern verfügbar. 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 unabhängig vom Alter der im Cache gespeicherten Antwort immer eine Neuvalidierungsanfrage gesendet.

Dies ist eine relativ 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 fällt auf das Netzwerk zurück)

Erstes Diagramm im Cache speichern

Offline-Web-Apps sind stark vom Cache abhängig. Bei nicht kritischen Assets, die nach und nach im Cache gespeichert werden können, ist Cache first die beste Option.

Wenn sich eine Antwort im Cache befindet, wird die Anfrage mit der im Cache gespeicherten Antwort ausgeführt und das Netzwerk wird überhaupt nicht verwendet. Wenn keine im Cache gespeicherte Antwort vorhanden ist, wird die Anfrage über eine Netzwerkanfrage ausgeführt und die Antwort wird im Cache gespeichert, damit die nächste Anfrage direkt aus dem Cache bereitgestellt wird.

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

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

Netzwerk zuerst (Netzwerk fällt auf Cache zurück)

Netzwerkdiagramm

Bei Anfragen, die häufig aktualisiert werden, ist die Strategie Netzwerk zuerst die ideale Lösung. Standardmäßig wird versucht, die neueste Antwort aus dem Netzwerk abzurufen. Wenn die Anfrage erfolgreich ist, wird die Antwort in den 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 vom Netzwerk erfüllt 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 Cache-Diagramm

Bei der Strategie Nur Cache werden Antworten aus einem Cache abgerufen. Das ist in der Workbox seltener, kann aber nützlich sein, wenn Sie einen eigenen Pre-Caching-Schritt 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 Lebenszyklusmethoden beim Abrufen und Caching einer Anfrage aufgerufen werden.

Von einer Strategie verwendeter Cache ändern

Sie können die verwendete Cache-Strategie ändern, indem Sie einen Cache-Namen angeben. Das ist nützlich, wenn Sie Ihre Assets trennen möchten, um das Debuggen zu erleichtern.

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

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

Plugins verwenden

Workbox bietet 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 der Option plugins nur Instanzen ü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 in Workbox auch eigene benutzerdefinierte Strategien erstellen. Dazu importieren und erweitern Sie die Strategy-Basisklasse aus workbox-strategies:

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(): Eine Anfragestrategie ausführen und einen Promise zurückgeben, der zu einem Response führt, wobei alle relevanten Plug-in-Callbacks aufgerufen werden.
  • handleAll(): Ähnlich wie handle(), gibt aber zwei Promise-Objekte zurück. Der erste Wert entspricht dem, was handle() zurückgibt. Der zweite Wert wird aufgelöst, wenn Zusagen, die event.waitUntil() in der Strategie hinzugefügt wurden, abgeschlossen sind.

Beide Anfragestrategien werden mit zwei Parametern aufgerufen:

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

Neue Strategie erstellen

Im folgenden Beispiel wird eine neue Strategie verwendet, 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 StrategyHandler-Klasse bietet eine Reihe von Abruf- und Cache-Aktionen, die verwendet werden können, wenn handle() oder handleAll() verwendet wird:

  • fetch: Ruft eine bestimmte Anfrage ab und ruft die Lebenszyklusmethoden requestWillFetch(), fetchDidSucceed() und fetchDidFail() des Plug-ins auf
  • cacheMatch: Er gleicht eine Anfrage aus dem Cache ab und ruft die Lebenszyklusmethoden cacheKeyWillBeUsed() und cachedResponseWillBeUsed() des Plug-ins auf.
  • cachePut: Speichert ein Anfrage/Antwort-Paar im Cache und ruft die Lebenszyklusmethoden cacheKeyWillBeUsed(), cacheWillUpdate() und cacheDidUpdate() des Plug-ins auf
  • fetchAndCachePut: Ruft fetch() auf und führt cachePut() im Hintergrund auf der von fetch() generierten Antwort aus.
  • hasCallback: Nimmt einen Rückruf als Eingabe entgegen und gibt „wahr“ zurück, wenn die Strategie mindestens ein Plug-in mit dem angegebenen Rückruf hat.
  • runCallbacks: Führt alle Plug-in-Callbacks aus, die einem bestimmten Namen entsprechen, in der Reihenfolge aus und übergibt ein bestimmtes Parameterobjekt (zusammengeführt mit dem aktuellen Plug-in-Status) als einziges Argument.
  • iterateCallbacks: Nimmt einen Callback entgegen und gibt eine Iterable mit übereinstimmenden Plug-in-Callbacks zurück.Dabei wird jeder Callback in den aktuellen Handler-Status eingewickelt. Wenn Sie also jeden Callback aufrufen, wird der übergebene Objektparameter mit dem aktuellen Status des Plug-ins zusammengeführt.
  • waitUntil: Fügt den Zusicherungen zur Verlängerung der Lebensdauer des Ereignisses, das mit der verarbeiteten Anfrage verknüpft ist (normalerweise eine FetchEvent), eine Zusicherung hinzu.
  • doneWaiting: Gibt ein Versprechen zurück, das erfüllt wird, sobald alle an waitUntil() übergebenen Versprechen abgeschlossen sind.
  • destroy: Die Strategie wird nicht mehr ausgeführt und alle ausstehenden waitUntil()-Zusagen werden sofort erfüllt.

Benutzerdefinierte Cache-Netzwerk-Wettlaufstrategie

Das folgende Beispiel basiert auf cache-network-race aus dem Offline-Kochbuch (das Workbox nicht bietet), 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 Logik für das Abrufen von Ereignissen verwenden möchten, können Sie mithilfe der Strategieklassen eine Anfrage über eine bestimmte Strategie ausführen.

So verwenden Sie beispielsweise die Strategie „Stale-while-Revalidate“:

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 den Referenzdokumenten zu Workbox-Strategien.

Typen

CacheFirst

Implementierung einer Cache-first-Anfragestrategie

Eine Cache-first-Strategie eignet sich für Assets, die überarbeitet wurden, z. B. URLs wie /styles/example.a8f5f1.css, da sie über einen längeren Zeitraum im Cache gespeichert werden können.

Wenn die Netzwerkanfrage fehlschlägt und keine Übereinstimmung im Cache gefunden wird, wird eine WorkboxError-Ausnahme geworfen.

Attribute

  • Konstruktor

    void

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

    Hinweis: Wenn eine benutzerdefinierte Strategieklasse die Basisklasse „Strategy“ erweitert und nicht mehr als diese Eigenschaften 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 eine Promise zurück, die zu einer Response aufgelöst wird. Dabei werden alle relevanten Plug-in-Callbacks aufgerufen.

    Wenn eine Strategieinstanz bei einer 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 Properties.

    • Gibt zurück

      Promise<Response>

  • handleAll

    void

    Ähnlich wie workbox-strategies.Strategy~handle, gibt aber nicht nur eine Promise zurück, die in eine Response aufgelöst wird, sondern ein Tupel von [response, done]-Versprechen. Das erste (response) entspricht dem, was handle() zurückgibt, und das letzte ist ein Versprechen, das aufgelöst wird, sobald alle Versprechen abgeschlossen sind, die event.waitUntil() im Rahmen der Ausführung der Strategie hinzugefügt wurden.

    Sie können auf die done-Zusicherung warten, um sicherzustellen, dass alle zusätzlichen Aufgaben, die von der Strategie ausgeführt werden (in der Regel das Caching von Antworten), 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 Properties.

    • Gibt zurück

      [Promise<Response>, Promise<void>]

      Ein Tupel aus [response, done]-Versprechen, mit dem ermittelt werden kann, wann die Antwort zurückgegeben wird und wann der Handler seine Arbeit abgeschlossen hat.

CacheOnly

Implementierung einer Nur-Cache-Anfragestrategie.

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

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

Attribute

  • Konstruktor

    void

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

    Hinweis: Wenn eine benutzerdefinierte Strategieklasse die Basisklasse „Strategy“ erweitert und nicht mehr als diese Eigenschaften 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 eine Promise zurück, die zu einer Response aufgelöst wird. Dabei werden alle relevanten Plug-in-Callbacks aufgerufen.

    Wenn eine Strategieinstanz bei einer 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 Properties.

    • Gibt zurück

      Promise<Response>

  • handleAll

    void

    Ähnlich wie workbox-strategies.Strategy~handle, gibt aber nicht nur eine Promise zurück, die in eine Response aufgelöst wird, sondern ein Tupel von [response, done]-Versprechen. Das erste (response) entspricht dem, was handle() zurückgibt, und das letzte ist ein Versprechen, das aufgelöst wird, sobald alle Versprechen abgeschlossen sind, die event.waitUntil() im Rahmen der Ausführung der Strategie hinzugefügt wurden.

    Sie können auf die done-Zusicherung warten, um sicherzustellen, dass alle zusätzlichen Aufgaben, die von der Strategie ausgeführt werden (in der Regel das Caching von Antworten), 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 Properties.

    • Gibt zurück

      [Promise<Response>, Promise<void>]

      Ein Tupel aus [response, done]-Versprechen, mit dem ermittelt werden kann, wann die Antwort zurückgegeben wird und wann der Handler seine Arbeit abgeschlossen hat.

NetworkFirst

Implementierung einer Netzwerk-first-Anfragestrategie

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

Wenn die Netzwerkanfrage fehlschlägt und keine Übereinstimmung im Cache gefunden wird, wird eine WorkboxError-Ausnahme geworfen.

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 eine Promise zurück, die zu einer Response aufgelöst wird. Dabei werden alle relevanten Plug-in-Callbacks aufgerufen.

    Wenn eine Strategieinstanz bei einer 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 Properties.

    • Gibt zurück

      Promise<Response>

  • handleAll

    void

    Ähnlich wie workbox-strategies.Strategy~handle, gibt aber nicht nur eine Promise zurück, die in eine Response aufgelöst wird, sondern ein Tupel von [response, done]-Versprechen. Das erste (response) entspricht dem, was handle() zurückgibt, und das letzte ist ein Versprechen, das aufgelöst wird, sobald alle Versprechen abgeschlossen sind, die event.waitUntil() im Rahmen der Ausführung der Strategie hinzugefügt wurden.

    Sie können auf die done-Zusicherung warten, um sicherzustellen, dass alle zusätzlichen Aufgaben, die von der Strategie ausgeführt werden (in der Regel das Caching von Antworten), 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 Properties.

    • Gibt zurück

      [Promise<Response>, Promise<void>]

      Ein Tupel aus [response, done]-Versprechen, mit dem ermittelt werden kann, wann die Antwort zurückgegeben 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

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 eine Promise zurück, die zu einer Response aufgelöst wird und alle relevanten Plug-in-Callbacks aufruft.

    Wenn eine Strategieinstanz bei einer 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 Properties.

    • Gibt zurück

      Promise<Response>

  • handleAll

    void

    Ähnlich wie workbox-strategies.Strategy~handle, gibt aber nicht nur eine Promise zurück, die in eine Response aufgelöst wird, sondern ein Tupel von [response, done]-Versprechen. Das erste (response) entspricht dem, was handle() zurückgibt, und das letzte ist ein Versprechen, das aufgelöst wird, sobald alle Versprechen abgeschlossen sind, die event.waitUntil() im Rahmen der Ausführung der Strategie hinzugefügt wurden.

    Sie können auf die done-Zusicherung warten, um sicherzustellen, dass alle zusätzlichen Aufgaben, die von der Strategie ausgeführt werden (in der Regel das Caching von Antworten), 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 Properties.

    • Gibt zurück

      [Promise<Response>, Promise<void>]

      Ein Tupel aus [response, done]-Versprechen, mit dem ermittelt werden kann, wann die Antwort zurückgegeben wird und wann der Handler seine Arbeit abgeschlossen hat.

NetworkOnlyOptions

Attribute

  • fetchOptions

    RequestInit optional

  • networkTimeoutSeconds

    number optional

  • Plug-ins

    WorkboxPlugin[] optional

StaleWhileRevalidate

Implementierung einer Stale-While-Revalidate-Anfragestrategie.

Ressourcen werden sowohl vom Cache als auch vom Netzwerk parallel angefordert. Die Strategie antwortet 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.

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

Wenn die Netzwerkanfrage fehlschlägt und keine Übereinstimmung im Cache gefunden wird, wird eine WorkboxError-Ausnahme geworfen.

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 eine Promise zurück, die zu einer Response aufgelöst wird. Dabei werden alle relevanten Plug-in-Callbacks aufgerufen.

    Wenn eine Strategieinstanz bei einer 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 Properties.

    • Gibt zurück

      Promise<Response>

  • handleAll

    void

    Ähnlich wie workbox-strategies.Strategy~handle, gibt aber nicht nur eine Promise zurück, die in eine Response aufgelöst wird, sondern ein Tupel von [response, done]-Versprechen. Das erste (response) entspricht dem, was handle() zurückgibt, und das letzte ist ein Versprechen, das aufgelöst wird, sobald alle Versprechen abgeschlossen sind, die event.waitUntil() im Rahmen der Ausführung der Strategie hinzugefügt wurden.

    Sie können auf die done-Zusicherung warten, um sicherzustellen, dass alle zusätzlichen Aufgaben, die von der Strategie ausgeführt werden (in der Regel das Caching von Antworten), 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 Properties.

    • Gibt zurück

      [Promise<Response>, Promise<void>]

      Ein Tupel aus [response, done]-Versprechen, mit dem ermittelt werden kann, wann die Antwort zurückgegeben 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 Optionen als öffentliche Instanzattribute fest.

    Hinweis: Wenn eine benutzerdefinierte Strategieklasse die Basisklasse „Strategy“ erweitert und nicht mehr als diese Eigenschaften 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 eine Promise zurück, die zu einer Response aufgelöst wird und alle relevanten Plug-in-Callbacks aufruft.

    Wenn eine Strategieinstanz bei einer 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 Properties.

    • Gibt zurück

      Promise<Response>

  • handleAll

    void

    Ähnlich wie workbox-strategies.Strategy~handle, gibt aber nicht nur eine Promise zurück, die in eine Response aufgelöst wird, sondern ein Tupel von [response, done]-Versprechen. Das erste (response) entspricht dem, was handle() zurückgibt, und das letzte ist ein Versprechen, das aufgelöst wird, sobald alle Versprechen abgeschlossen sind, die event.waitUntil() im Rahmen der Ausführung der Strategie hinzugefügt wurden.

    Sie können auf die done-Zusicherung warten, um sicherzustellen, dass alle zusätzlichen Aufgaben, die von der Strategie ausgeführt werden (in der Regel das Caching von Antworten), 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 Properties.

    • Gibt zurück

      [Promise<Response>, Promise<void>]

      Ein Tupel aus [response, done]-Versprechen, mit dem ermittelt werden kann, wann die Antwort zurückgegeben wird und wann der Handler seine Arbeit abgeschlossen hat.

StrategyHandler

Eine Klasse, die jedes Mal erstellt wird, wenn eine Strategieinstanz workbox-strategies.Strategy~handle oder workbox-strategies.Strategy~handleAll aufruft. Sie umschließt alle Abruf- und Cache-Aktionen in Plugin-Callbacks und überwacht, wann die Strategie „fertig“ ist (d. h. alle hinzugefügten event.waitUntil()-Versprechen sind erfüllt).

Attribute

  • Konstruktor

    void

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

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

    Die constructor-Funktion sieht so aus:

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

  • event

    ExtendableEvent

  • params

    beliebig optional

  • Anfrage

    Anfrage

  • URL

    URL optional

  • cacheMatch

    void

    Übereinstimmung mit einer Anfrage aus dem Cache (und Aufruf aller anwendbaren Plugin-Callback-Methoden) mithilfe der im Strategieobjekt definierten cacheName, matchOptions und plugins.

    Bei Verwendung dieser Methode werden die folgenden Methoden für den Plugin-Lebenszyklus aufgerufen:

    • 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 übereinstimmende Antwort, falls gefunden.

  • cachePut

    void

    Speichert ein Anfrage/Antwort-Paar im Cache und ruft alle anwendbaren Plug-in-Callback-Methoden auf, die im Strategieobjekt für cacheName und plugins definiert sind.

    Bei Verwendung dieser Methode werden die folgenden Methoden für den Plugin-Lebenszyklus aufgerufen:

    • 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 die Antwort aufgrund von „cacheWillUpdate“ nicht im Cache gespeichert wurde, und true andernfalls.

  • löschen

    void

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

    Die destroy-Funktion sieht so aus:

    () => {...}

  • doneWaiting

    void

    Gibt ein Versprechen zurück, das aufgelöst wird, sobald alle an workbox-strategies.StrategyHandler~waitUntil übergebenen Versprechen erfüllt sind.

    Hinweis: Alle nach dem Abschluss von doneWaiting() ausgeführten Arbeiten müssen 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 Rückrufmethoden des Plug-ins auf) und verwendet dabei die fetchOptions (für Anfragen, die nicht zur Navigation gehören) und plugins, die im Strategy-Objekt definiert sind.

    Bei Verwendung dieser Methode werden die folgenden Methoden für den Plugin-Lebenszyklus aufgerufen:

    • 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() auf die von this.fetch() generierte Antwort aus.

    Durch den Aufruf von this.cachePut() wird automatisch this.waitUntil() aufgerufen. Du musst 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

    Die Liste der Plug-ins wird auf den cacheKeyWillBeUsed-Callback geprüft und alle gefundenen Callbacks werden nacheinander ausgeführt. Das vom letzten Plug-in zurückgegebene endgültige Request-Objekt wird als Cache-Schlüssel für Cache-Lesungen und/oder -Schreibvorgänge verwendet. 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 „wahr“ zurück, wenn die Strategie mindestens ein Plug-in mit dem angegebenen Rückruf hat.

    Die hasCallback-Funktion sieht so aus:

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

    • name

      C

      Der Name des Rückrufs, nach dem gesucht werden soll.

    • Gibt zurück

      boolean

  • iterateCallbacks

    void

    Nimmt einen Callback entgegen und gibt eine Iterable mit übereinstimmenden Plugin-Callbacks zurück.Dabei wird jeder Callback mit dem aktuellen Handler-Status umschlossen. Wenn Sie also einen Callback aufrufen, wird der übergebene Objektparameter 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 mit dem angegebenen Namen übereinstimmen, und übergibt das angegebene Parameterobjekt (zusammengeführt mit dem aktuellen Plug-in-Status) als einziges Argument.

    Hinweis: Da bei dieser Methode alle Plugins ausgeführt werden, eignet sie sich nicht für Fälle, in denen der Rückgabewert eines Callbacks angewendet werden muss, bevor der nächste Callback aufgerufen wird. Wie du in diesem Fall vorgehen solltest, erfährst du unten.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 bei der Ausführung jedes Callbacks als erster (und einziger) Parameter ü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ügen Sie den [extend lifetime promises]https://w3c.github.io/ServiceWorker/#extendableevent-extend-lifetime-promises des Ereignisses, das mit der verarbeiteten Anfrage verknüpft ist (normalerweise eine FetchEvent), ein Versprechen hinzu.

    Hinweis: Sie können auf workbox-strategies.StrategyHandler~doneWaiting warten, um zu erfahren, wann alle hinzugefügten Zusagen erfüllt wurden.

    Die waitUntil-Funktion sieht so aus:

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

    • promise

      Promise<T>

      Ein Versprechen, das zu den Zusagen zur Verlängerung der Lebensdauer des Ereignisses hinzugefügt wird, 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