Workbox-Precaching

Eines der Features von Dienst-Workern ist die Möglichkeit, eine Reihe von Dateien beim Installieren des Dienst-Workers im Cache zu speichern. Dies wird oft als „Vorab-Caching“ bezeichnet, da Sie Inhalte vor der Verwendung des Service Workers im Cache speichern.

Der Hauptgrund dafür ist, dass Entwickler so die Kontrolle über den Cache haben. Sie können also festlegen, wann und wie lange eine Datei im Cache gespeichert wird, und sie dem Browser ohne Netzwerkzugriff zur Verfügung stellen. So können Web-Apps erstellt werden, die auch offline funktionieren.

Workbox vereinfacht die API und sorgt dafür, dass Assets effizient heruntergeladen werden, sodass das Vorab-Caching deutlich einfacher wird.

Funktionsweise des Workbox-Precaching

Wenn eine Webanwendung zum ersten Mal geladen wird, prüft workbox-precaching alle Assets, die Sie herunterladen möchten, entfernt alle Duplikate und verbindet die entsprechenden Dienstworker-Ereignisse, um die Assets herunterzuladen und zu speichern. URLs, die bereits Informationen zur Versionierung (z. B. einen Inhalts-Hash) enthalten, werden ohne weitere Änderungen als Cacheschlüssel verwendet. URLs, die keine Versionsinformationen enthalten, haben einen zusätzlichen URL-Abfrageparameter, der an den Cache-Schlüssel angehängt wird. Er stellt einen Hash des Inhalts dar, der von Workbox zum Zeitpunkt des Builds generiert wird.

workbox-precaching führt all dies während des install-Ereignisses des Dienstarbeiters aus.

Wenn ein Nutzer Ihre Webanwendung später noch einmal besucht und Sie einen neuen Service Worker mit anderen vorab im Cache gespeicherten Assets haben, sieht sich workbox-precaching die neue Liste an und ermittelt anhand der Überarbeitung, welche Assets völlig neu sind und welche der vorhandenen Assets aktualisiert werden müssen. Alle neuen Assets oder aktualisierten Versionen werden dem Cache während des install-Ereignisses des neuen Service Workers hinzugefügt.

Dieser neue Dienst-Worker wird erst dann verwendet, um auf Anfragen zu reagieren, wenn sein activate-Ereignis ausgelöst wurde. Im Ereignis activate prüft workbox-precaching, ob es im Cache Assets gibt, die nicht mehr in der Liste der aktuellen URLs enthalten sind, und entfernt diese aus dem Cache.

workbox-precaching führt diese Schritte jedes Mal aus, wenn Ihr Service Worker installiert und aktiviert wird. So wird sichergestellt, dass der Nutzer die neuesten Assets hat, und es werden nur die Dateien heruntergeladen, die sich geändert haben.

Bereits gecachte Antworten senden

Wenn Sie precacheAndRoute() oder addRoute() aufrufen, wird eine Route erstellt, die Anfragen für vorab im Cache gespeicherte URLs abgleicht.

Die in dieser Route verwendete Antwortstrategie ist Cache-first: Die vorab im Cache gespeicherte Antwort wird verwendet, es sei denn, diese Antwort ist aufgrund eines unerwarteten Fehlers nicht vorhanden. In diesem Fall wird stattdessen eine Netzwerkantwort verwendet.

Die Reihenfolge, in der Sie precacheAndRoute() oder addRoute() aufrufen, ist wichtig. Normalerweise sollten Sie sie früh in Ihrer Service Worker-Datei aufrufen, bevor Sie zusätzliche Routen bei registerRoute() registrieren. Wenn Sie zuerst registerRoute() aufgerufen haben und diese Route mit einer eingehenden Anfrage übereinstimmt, wird die in dieser zusätzlichen Route definierte Strategie verwendet, um zu antworten, anstatt die von workbox-precaching verwendete Cache-first-Strategie.

Erklärung der Precache-Liste

Für workbox-precaching wird ein Array von Objekten mit den Properties url und revision erwartet. Dieses Array wird manchmal auch als Pre-Cache-Manifest bezeichnet:

import {precacheAndRoute} from 'workbox-precaching';

precacheAndRoute([
  {url: '/index.html', revision: '383676'},
  {url: '/styles/app.0c9a31.css', revision: null},
  {url: '/scripts/app.0d5770.js', revision: null},
  // ... other entries ...
]);

Diese Liste verweist auf eine Reihe von URLs, die jeweils eigene Informationen zur Überarbeitung enthalten.

Für das zweite und dritte Objekt im obigen Beispiel ist die revision-Eigenschaft auf null festgelegt. Das liegt daran, dass sich die Informationen zur Versionierung in der URL selbst befinden. Das ist im Allgemeinen eine Best Practice für statische Assets.

Das erste Objekt (/index.html) legt explizit eine Revisionsanfrage fest, die ein automatisch generierter Hash des Dateiinhalts ist. Im Gegensatz zu JavaScript- und CSS-Ressourcen können HTML-Dateien in ihren URLs in der Regel keine Informationen zur Versionsverwaltung enthalten. Andernfalls würden Links zu diesen Dateien im Web jedes Mal aufgelöst, wenn sich der Inhalt der Seite ändert.

Wenn Sie eine Versionseigenschaft an precacheAndRoute() übergeben, kann Workbox erkennen, wann sich die Datei geändert hat, und sie entsprechend aktualisieren.

Workbox bietet Tools, mit denen Sie diese Liste erstellen können:

  • workbox-build: Dies ist ein Node-Paket, das in einer Gulp-Aufgabe oder als npm-Laufscript verwendet werden kann.
  • workbox-webpack-plugin: Webpack-Nutzer können dieses Plug-in verwenden.
  • workbox-cli: Mit unserer Befehlszeile können Sie auch die Liste der Assets generieren und Ihrem Service Worker hinzufügen.

Eingehende Anfragen für vorab im Cache gespeicherte Dateien

workbox-precaching manipuliert standardmäßig die eingehenden Netzwerkanfragen, um vorab im Cache gespeicherte Dateien abzugleichen. Dies berücksichtigt gängige Praktiken im Web.

Eine Anfrage für / kann beispielsweise in der Regel mit der Datei unter /index.html beantwortet werden.

Unten finden Sie eine Liste der Manipulationen, die workbox-precaching standardmäßig vornimmt, und wie Sie dieses Verhalten ändern können.

URL-Parameter ignorieren

Anfragen mit Suchparametern können so geändert werden, dass bestimmte oder alle Werte entfernt werden.

Standardmäßig werden Suchparameter entfernt, die mit utm_ beginnen oder genau mit fbclid übereinstimmen. Das bedeutet, dass eine Anfrage für /about.html?utm_campaign=abcd mit einem vorab im Cache gespeicherten Eintrag für /about.html erfüllt wird.

Mit ignoreURLParametersMatching können Sie eine andere Gruppe von Suchparametern ignorieren:

import {precacheAndRoute} from 'workbox-precaching';

precacheAndRoute(
  [
    {url: '/index.html', revision: '383676'},
    {url: '/styles/app.0c9a31.css', revision: null},
    {url: '/scripts/app.0d5770.js', revision: null},
  ],
  {
    // Ignore all URL parameters.
    ignoreURLParametersMatching: [/.*/],
  }
);

Verzeichnisindex

Anfragen, die auf / enden, werden standardmäßig mit Einträgen abgeglichen, an deren Ende ein index.html angehängt ist. Das bedeutet, dass eine eingehende Anfrage für / automatisch mit dem vorab im Cache gespeicherten Eintrag /index.html verarbeitet werden kann.

Sie können dies ändern oder vollständig deaktivieren, indem Sie directoryIndex auf eine der folgenden Optionen festlegen:

import {precacheAndRoute} from 'workbox-precaching';

precacheAndRoute(
  [
    {url: '/index.html', revision: '383676'},
    {url: '/styles/app.0c9a31.css', revision: null},
    {url: '/scripts/app.0d5770.js', revision: null},
  ],
  {
    directoryIndex: null,
  }
);

Saubere URLs

Wenn eine Anfrage nicht mit dem Pre-Cache übereinstimmt, fügen wir am Ende .html hinzu, um „saubere“ URLs (auch „schöne“ URLs genannt) zu unterstützen. Das bedeutet, dass eine Anfrage wie /about vom vorab im Cache gespeicherten Eintrag für /about.html verarbeitet wird.

Sie können dieses Verhalten deaktivieren, indem Sie cleanUrls so festlegen:

import {precacheAndRoute} from 'workbox-precaching';

precacheAndRoute([{url: '/about.html', revision: 'b79cd4'}], {
  cleanUrls: false,
});

Benutzerdefinierte Manipulationen

Wenn Sie benutzerdefinierte Übereinstimmungen von eingehenden Anfragen mit vorab im Cache gespeicherten Assets definieren möchten, können Sie dies mit der Option urlManipulation tun. Dies sollte ein Rückruf sein, der ein Array mit möglichen Übereinstimmungen zurückgibt.

import {precacheAndRoute} from 'workbox-precaching';

precacheAndRoute(
  [
    {url: '/index.html', revision: '383676'},
    {url: '/styles/app.0c9a31.css', revision: null},
    {url: '/scripts/app.0d5770.js', revision: null},
  ],
  {
    urlManipulation: ({url}) => {
      // Your logic goes here...
      return [alteredUrlOption1, alteredUrlOption2];
    },
  }
);

Erweiterte Nutzung

PrecacheController direkt verwenden

Standardmäßig richtet workbox-precaching die install- und activate-Listener für Sie ein. Für Entwickler, die mit Service Workern vertraut sind, ist dies möglicherweise nicht wünschenswert, wenn Sie mehr Kontrolle benötigen.

Anstatt den Standardexport zu verwenden, kannst du direkt den Befehl PrecacheController verwenden, um dem Pre-Cache Elemente hinzuzufügen, festzulegen, wann diese Assets installiert werden, und wann die Bereinigung erfolgen soll.

import {PrecacheController} from 'workbox-precaching';

const precacheController = new PrecacheController();
precacheController.addToCacheList([
  {url: '/styles/example-1.abcd.css', revision: null},
  {url: '/styles/example-2.1234.css', revision: null},
  {url: '/scripts/example-1.abcd.js', revision: null},
  {url: '/scripts/example-2.1234.js', revision: null},
]);

precacheController.addToCacheList([{
  url: '/index.html',
  revision: 'abcd',
}, {
  url: '/about.html',
  revision: '1234',
}]);

self.addEventListener('install', (event) => {
  // Passing in event is required in Workbox v6+
  event.waitUntil(precacheController.install(event));
});

self.addEventListener('activate', (event) => {
  // Passing in event is required in Workbox v6+
  event.waitUntil(precacheController.activate(event));
});

self.addEventListener('fetch', (event) => {
  const cacheKey = precacheController.getCacheKeyForURL(event.request.url);
  event.respondWith(caches.match(cacheKey).then(...));
});

Vorab gecachte Assets direkt lesen

Manchmal müssen Sie ein vorab im Cache gespeichertes Asset direkt lesen, außerhalb des Kontexts der automatischen Weiterleitung durch workbox-precaching. So können Sie beispielsweise teilweise HTML-Vorlagen vorab im Cache speichern, die dann abgerufen und beim Erstellen einer vollständigen Antwort verwendet werden müssen.

Im Allgemeinen kannst du die Cache Storage API verwenden, um die vorab im Cache gespeicherten Response-Objekte abzurufen. Es gibt jedoch einen Haken: Der URL-Cache-Schlüssel, der beim Aufrufen von cache.match() verwendet werden muss, kann einen Versionierungsparameter enthalten, der von workbox-precaching automatisch erstellt und verwaltet wird.

Um den richtigen Cache-Schlüssel zu erhalten, kannst du getCacheKeyForURL() aufrufen und die ursprüngliche URL übergeben. Mit dem Ergebnis kannst du dann eine cache.match() auf dem entsprechenden Cache ausführen.

import {cacheNames} from 'workbox-core';
import {getCacheKeyForURL} from 'workbox-precaching';

const cache = await caches.open(cacheNames.precache);
const response = await cache.match(getCacheKeyForURL('/precached-file.html'));

Wenn Sie nur das vorab im Cache gespeicherte Response-Objekt benötigen, können Sie alternativ matchPrecache() aufrufen. Dabei wird automatisch der richtige Cache-Schlüssel verwendet und im richtigen Cache gesucht:

import {matchPrecache} from 'workbox-precaching';

const response = await matchPrecache('/precached-file.html');

Alte Precaches bereinigen

Die meisten Releases von Workbox verwenden dasselbe Format zum Speichern von vorab im Cache gespeicherten Daten. Vorab im Cache gespeicherte Daten, die mit älteren Versionen von Workbox erstellt wurden, können in der Regel von neueren Releases unverändert verwendet werden. In seltenen Fällen gibt es jedoch eine gravierende Änderung beim Pre-Caching-Speicher, die dazu führt, dass bestehende Nutzer alles noch einmal herunterladen müssen und zuvor im Cache gespeicherte Daten veraltet sind. (Eine solche Änderung wurde zwischen den Versionen 3 und 4 von Workbox vorgenommen.)

Diese veralteten Daten sollten den normalen Betrieb nicht beeinträchtigen. Sie tragen jedoch zum Gesamtverbrauch Ihres Speicherkontingents bei. Es kann für Ihre Nutzer einfacher sein, sie explizit zu löschen. Fügen Sie dazu cleanupOutdatedCaches() zu Ihrem Dienstworker hinzu oder legen Sie cleanupOutdatedCaches: true fest, wenn Sie einen der Build-Tools von Workbox zum Generieren Ihres Dienstworkers verwenden.

Subresource Integrity verwenden

Einige Entwickler benötigen möglicherweise die zusätzlichen Garantien, die durch die Durchsetzung der Subressourcenintegrität beim Abrufen von vorab im Cache gespeicherten URLs aus dem Netzwerk geboten werden.

Jedem Eintrag im Pre-Cache-Manifest kann eine zusätzliche optionale Eigenschaft namens integrity hinzugefügt werden. Wenn angegeben, wird er beim Erstellen des Request, mit dem der Cache gefüllt wird, als integrity-Wert verwendet. Bei einer Abweichung schlägt der Pre-Caching-Vorgang fehl.

Die Entscheidung, welche Manifesteinträge für die Vorab-Caching-Funktion integrity-Properties haben sollten, und die Ermittlung der entsprechenden Werte fallen nicht in den Zuständigkeitsbereich der Build-Tools von Workbox. Stattdessen sollten Entwickler, die diese Funktion aktivieren möchten, das von Workbox generierte Pre-Cache-Manifest ändern, um die entsprechenden Informationen selbst hinzuzufügen. Die Option manifestTransform in der Build-Tools-Konfiguration von Workbox kann Ihnen dabei helfen:

const ssri = require('ssri');

const integrityManifestTransform = (originalManifest, compilation) => {
  const warnings = [];
  const manifest = originalManifest.map(entry => {
    // If some criteria match:
    if (entry.url.startsWith('...')) {
      // This has to be a synchronous function call, for example:
      // compilation will be set when using workbox-webpack-plugin.
      // When using workbox-build directly, you can read the file's
      // contents from disk using, e.g., the fs module.
      const asset = compilation.getAsset(entry.url);
      entry.integrity = ssri.fromData(asset.source.source()).toString();

      // Push a message to warnings if needed.
    }
    return entry;
  });

  return {warnings, manifest};
};

// Then add manifestTransform: [integrityManifestTransform]
// to your Workbox build configuration.

Typen

CleanupResult

Attribute

  • deletedCacheRequests

    String[]

InstallResult

Attribute

  • notUpdatedURLs

    String[]

  • updatedURLs

    String[]

PrecacheController

Führt ein effizientes Vorab-Caching von Assets durch.

Attribute

  • Konstruktor

    void

    Erstelle einen neuen PrecacheController.

    Die constructor-Funktion sieht so aus: 

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

    • Optionen

      PrecacheControllerOptions optional

  • Strategie

    Strategie

  • aktivieren

    void

    Löscht Assets, die nicht mehr im aktuellen Pre-Cache-Manifest vorhanden sind. Rufen Sie diese Methode über das Service Worker-Ereignis „activate“ auf.

    Hinweis: Diese Methode ruft event.waitUntil() für Sie auf. Sie müssen sie also nicht selbst in Ihren Ereignishandlern aufrufen.

    Die activate-Funktion sieht so aus: 

    (event: ExtendableEvent) => {...}

    • event

      ExtendableEvent

  • addToCacheList

    void

    Mit dieser Methode werden der Pre-Cache-Liste Elemente hinzugefügt, Duplikate entfernt und die Gültigkeit der Informationen geprüft.

    Die addToCacheList-Funktion sieht so aus: 

    (entries: (string | PrecacheEntry)[]) => {...}

    • entries

      (string | PrecacheEntry)[]

      Array mit Einträgen, die vorab im Cache gespeichert werden sollen.

  • createHandlerBoundToURL

    void

    Gibt eine Funktion zurück, die url im Precache sucht (unter Berücksichtigung der Versionsinformationen) und die entsprechende Response zurückgibt.

    Die createHandlerBoundToURL-Funktion sieht so aus: 

    (url: string) => {...}

    • URL

      String

      Die vorab im Cache gespeicherte URL, die zum Abrufen der Response verwendet wird.

  • getCacheKeyForURL

    void

    Gibt den Cache-Schlüssel zurück, der zum Speichern einer bestimmten URL verwendet wurde. Wenn diese URL nicht versioniert ist, z. B. „/index.html“, ist der Cache-Schlüssel die ursprüngliche URL mit einem angehängten Suchparameter.

    Die getCacheKeyForURL-Funktion sieht so aus: 

    (url: string) => {...}

    • URL

      String

      Eine URL, deren Cache-Schlüssel Sie abrufen möchten.

    • Gibt zurück

      String

      Die versionierte URL, die einem Cache-Schlüssel für die ursprüngliche URL entspricht, oder „undefiniert“, wenn diese URL nicht vorab im Cache gespeichert ist.

  • getCachedURLs

    void

    Gibt eine Liste aller URLs zurück, die vom aktuellen Service Worker vorab im Cache gespeichert wurden.

    Die getCachedURLs-Funktion sieht so aus: 

    () => {...}

    • Gibt zurück

      String[]

      Die vorab im Cache gespeicherten URLs.

  • getIntegrityForCacheKey

    void

    Die getIntegrityForCacheKey-Funktion sieht so aus: 

    (cacheKey: string) => {...}

    • cacheKey

      String

    • Gibt zurück

      String

      Die Integrität der Unterressource, die mit dem Cache-Schlüssel verknüpft ist, oder „undefiniert“, wenn sie nicht festgelegt ist.

  • getURLsToCacheKeys

    void

    Gibt eine Zuordnung einer vorab im Cache gespeicherten URL zum entsprechenden Cache-Schlüssel zurück. Dabei werden die Revisionshinweise für die URL berücksichtigt.

    Die getURLsToCacheKeys-Funktion sieht so aus: 

    () => {...}

    • Gibt zurück

      Map<stringstring>

      Eine URL zur Cache-Schlüsselzuordnung.

  • installieren

    void

    Neue und aktualisierte Assets werden vorab im Cache gespeichert. Rufen Sie diese Methode über das Service Worker-Ereignis „install“ auf.

    Hinweis: Diese Methode ruft event.waitUntil() für Sie auf. Sie müssen sie also nicht selbst in Ihren Ereignishandlern aufrufen.

    Die install-Funktion sieht so aus: 

    (event: ExtendableEvent) => {...}

    • event

      ExtendableEvent

  • matchPrecache

    void

    Dieser Wert kann als Ersatz für cache.match() verwendet werden. Es gibt jedoch folgende Unterschiede:

    • Es kennt den Namen des Pre-Caches und sucht nur in diesem Cache.
    • Sie können eine „ursprüngliche“ URL ohne Versionierungsparameter übergeben. Daraufhin wird automatisch der richtige Cache-Schlüssel für die aktuell aktive Version dieser URL ermittelt.

    Beispiel: matchPrecache('index.html') findet die richtige vorab im Cache gespeicherte Antwort für den aktuell aktiven Dienst-Worker, auch wenn der tatsächliche Cache-Schlüssel '/index.html?__WB_REVISION__=1234abcd' ist.

    Die matchPrecache-Funktion sieht so aus: 

    (request: string | Request) => {...}

    • Anfrage

      String | Anfrage

      Der Schlüssel (ohne Parameter zur Versionsverwaltung), der im Precache-Speicher gesucht werden soll.

    • Gibt zurück

      Promise<Response>

  • precache

    void

    Fügen Sie der Pre-Cache-Liste Elemente hinzu, entfernen Sie alle Duplikate und speichern Sie die Dateien im Cache, wenn der Dienst-Worker installiert wird.

    Diese Methode kann mehrmals aufgerufen werden.

    Die precache-Funktion sieht so aus: 

    (entries: (string | PrecacheEntry)[]) => {...}

PrecacheEntry

Attribute

  • Integrität

    String optional

  • Revision

    String optional

  • URL

    String

PrecacheFallbackPlugin

Mit PrecacheFallbackPlugin können Sie eine „Offline-Fallback-Antwort“ angeben, die verwendet werden soll, wenn eine bestimmte Strategie keine Antwort generieren kann.

Dazu wird der handlerDidError-Plug-in-Callback abgefangen und eine vorab im Cache gespeicherte Antwort zurückgegeben, wobei der erwartete Revisionparameter automatisch berücksichtigt wird.

Sofern Sie dem Konstruktor nicht explizit eine PrecacheController-Instanz übergeben, wird die Standardinstanz verwendet. Im Allgemeinen verwenden die meisten Entwickler die Standardeinstellung.

Attribute

  • Konstruktor

    void

    Erstellt ein neues PrecacheFallbackPlugin mit der zugehörigen fallbackURL.

    Die constructor-Funktion sieht so aus: 

    (config: object) => {...}

    • config

      Objekt

      • fallbackURL

        String

        Eine vorab im Cache gespeicherte URL, die als Fallback verwendet wird, wenn die zugehörige Strategie keine Antwort generieren kann.

      • precacheController

        PrecacheController optional

PrecacheRoute

Eine Unterklasse von workbox-routing.Route, die eine workbox-precaching.PrecacheController-Instanz annimmt und verwendet, um eingehende Anfragen abzugleichen und das Abrufen von Antworten aus dem Precache zu steuern.

Attribute

PrecacheRouteOptions

Attribute

  • cleanURLs

    boolescher Wert optional

  • directoryIndex

    String optional

  • ignoreURLParametersMatching

    RegExp[] optional

  • urlManipulation

    urlManipulation optional

PrecacheStrategy

Eine workbox-strategies.Strategy-Implementierung, die speziell für die Verwendung mit workbox-precaching.PrecacheController entwickelt wurde, um vorab im Cache gespeicherte Assets sowohl zu cachen als auch abzurufen.

Hinweis: Beim Erstellen einer PrecacheController wird automatisch eine Instanz dieser Klasse erstellt. Sie müssen sie in der Regel nicht selbst erstellen.

Attribute

  • Konstruktor

    void

    Die constructor-Funktion sieht so aus: 

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

    • Optionen

      PrecacheStrategyOptions optional

  • cacheName

    String

  • fetchOptions

    RequestInit optional

  • matchOptions

    CacheQueryOptions optional

  • Plug-ins

    WorkboxPlugin[]

  • copyRedirectedCacheableResponsesPlugin

    WorkboxPlugin

  • defaultPrecacheCacheabilityPlugin

    WorkboxPlugin

  • _awaitComplete

    void

    Die _awaitComplete-Funktion sieht so aus: 

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

    • responseDone

      Promise<Response>

    • Handler

      StrategyHandler

    • 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>

  • _handleFetch

    void

    Die _handleFetch-Funktion sieht so aus: 

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

    • Gibt zurück

      Promise<Response>

  • _handleInstall

    void

    Die _handleInstall-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.

urlManipulation()

workbox-precaching.urlManipulation(
  { url }: object,
)

Typ

Funktion

Parameter

  • { url }

    Objekt

    • URL

      URL

Ausgabe

  • URL[]

Methoden

addPlugins()

workbox-precaching.addPlugins(
  plugins: WorkboxPlugin[],
)

Fügt der Pre-Caching-Strategie Plug-ins hinzu.

Parameter

addRoute()

workbox-precaching.addRoute(
  options?: PrecacheRouteOptions,
)

Fügen Sie dem Dienst-Worker einen fetch-Listener hinzu, der auf [Netzwerkanfragen]https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers#Custom_responses_to_requests mit vorab im Cache gespeicherten Assets antwortet.

Bei Anfragen für Assets, die nicht vorab im Cache gespeichert sind, wird nicht auf FetchEvent geantwortet. Das Ereignis wird dann an andere fetch-Ereignis-Listener weitergeleitet.

Parameter

cleanupOutdatedCaches()

workbox-precaching.cleanupOutdatedCaches()

Fügt einen activate-Ereignis-Listener hinzu, der inkompatible Pre-Caches beseitigt, die von älteren Versionen von Workbox erstellt wurden.

createHandlerBoundToURL()

workbox-precaching.createHandlerBoundToURL(
  url: string,
)

Hilfsfunktion, die PrecacheController#createHandlerBoundToURL auf der Standardinstanz PrecacheController aufruft.

Wenn Sie Ihre eigene PrecacheController erstellen, rufen Sie die PrecacheController#createHandlerBoundToURL für diese Instanz auf, anstatt diese Funktion zu verwenden.

Parameter

  • URL

    String

    Die vorab im Cache gespeicherte URL, die zum Abrufen der Response verwendet wird.

Ausgabe

getCacheKeyForURL()

workbox-precaching.getCacheKeyForURL(
  url: string,
)

Nimmt eine URL entgegen und gibt die entsprechende URL zurück, mit der der Eintrag im Precache-Cache abgerufen werden kann.

Wenn eine relative URL angegeben wird, wird der Speicherort der Service Worker-Datei als Basis verwendet.

Bei vorab im Cache gespeicherten Einträgen ohne Überarbeitungsinformationen entspricht der Cache-Schlüssel der ursprünglichen URL.

Bei vorab im Cache gespeicherten Einträgen mit Versionsinformationen ist der Cache-Schlüssel die ursprüngliche URL mit einem zusätzlichen Abfrageparameter, der zum Überwachen der Versionsinformationen verwendet wird.

Parameter

  • URL

    String

    Die URL, deren Cache-Schlüssel gesucht werden soll.

Ausgabe

  • String | undefiniert

    Der Cache-Schlüssel, der dieser URL entspricht.

matchPrecache()

workbox-precaching.matchPrecache(
  request: string | Request,
)

Hilfsfunktion, die PrecacheController#matchPrecache auf der Standardinstanz PrecacheController aufruft.

Wenn Sie Ihre eigene PrecacheController erstellen, rufen Sie PrecacheController#matchPrecache für diese Instanz auf, anstatt diese Funktion zu verwenden.

Parameter

  • Anfrage

    String | Anfrage

    Der Schlüssel (ohne Parameter zur Versionsverwaltung), der im Precache-Speicher gesucht werden soll.

Ausgabe

  • Promise<Response | undefined>

precache()

workbox-precaching.precache(
  entries: (string | PrecacheEntry)[],
)

Fügen Sie der Pre-Cache-Liste Elemente hinzu, entfernen Sie alle Duplikate und speichern Sie die Dateien im Cache, wenn der Dienstworker installiert wird.

Diese Methode kann mehrmals aufgerufen werden.

Hinweis: Bei dieser Methode werden keine der im Cache gespeicherten Dateien bereitgestellt. Es werden nur Dateien vorab im Cache gespeichert. Wenn du auf eine Netzwerkanfrage antworten möchtest, ruf workbox-precaching.addRoute auf.

Wenn du ein einzelnes Array von Dateien vor dem Cachen hast, kannst du einfach workbox-precaching.precacheAndRoute aufrufen.

Parameter

precacheAndRoute()

workbox-precaching.precacheAndRoute(
  entries: (string | PrecacheEntry)[],
  options?: PrecacheRouteOptions,
)

Mit dieser Methode werden der Liste für die Vorab-Caching-Dateien Einträge und eine Route hinzugefügt, um auf Abruf-Ereignisse zu reagieren.

Dies ist eine praktische Methode, mit der workbox-precaching.precache und workbox-precaching.addRoute in einem einzigen Aufruf aufgerufen werden.

Parameter