pre-memorizzazione nella cache della casella di lavoro

Una caratteristica dei service worker è la possibilità di salvare un insieme di file nella cache durante l'installazione del service worker. Questa situazione viene spesso denominata "precaching", poiché i contenuti vengono memorizzati nella cache prima del service worker utilizzato.

Il motivo principale di questa scelta è che gli sviluppatori hanno il controllo sulla cache, il che significa che possono determinare quando e per quanto tempo un file viene memorizzato nella cache e per pubblicarlo nel browser senza accedere alla rete, il che significa che possono essere utilizzati per creare app web che funzionano offline.

Workbox elimina molto il lavoro pesante di pre-memorizzazione nella cache semplificando l'API e garantendo che gli asset vengano scaricati in modo efficiente.

Come funziona la pre-memorizzazione nella cache di lavoro

Quando un'app web viene caricata per la prima volta, workbox-precaching controlla tutti gli asset che vuoi scaricare, rimuove eventuali duplicati e collega gli eventi dei service worker pertinenti per scaricare e archiviare gli asset. Gli URL che già includono informazioni sul controllo delle versioni (ad esempio, un hash dei contenuti) vengono utilizzati come chiavi cache senza ulteriori modifiche. Gli URL che non includono informazioni sul controllo delle versioni hanno un parametro di query URL aggiuntivo aggiunto alla chiave cache che rappresenta un hash dei contenuti generato da Workbox al momento della creazione.

workbox-precaching esegue queste operazioni durante l'evento install del service worker.

Quando un utente accede di nuovo alla tua applicazione web in un secondo momento e hai un nuovo service worker con diversi asset prememorizzati nella cache, workbox-precaching esaminerà il nuovo elenco e determinerà quali asset sono completamente nuovi e quali esistenti devono essere aggiornati, in base alla relativa revisione. Eventuali nuovi asset o revisioni in fase di aggiornamento verranno aggiunti alla cache durante l'evento install del nuovo service worker.

Questo nuovo service worker non verrà utilizzato per rispondere alle richieste finché non verrà attivato il relativo evento activate. È nell'evento activate che workbox-precaching controlla se sono presenti asset memorizzati nella cache che non sono più presenti nell'elenco degli URL correnti e li rimuove dalla cache.

workbox-precaching eseguirà questi passaggi ogni volta che il service worker viene installato e attivato, assicurando che l'utente disponga degli asset più recenti e scaricando solo i file che sono stati modificati.

Pubblicazione di risposte pre-memorizzate nella cache

La chiamata a precacheAndRoute() o addRoute() crea una route che corrisponde alle richieste di URL pre-memorizzati nella cache.

La strategia di risposta utilizzata in questa route è cache-first: verrà utilizzata la risposta prememorizzata nella cache, a meno che non sia presente una risposta memorizzata nella cache (a causa di un errore imprevisto), nel qual caso verrà utilizzata una risposta di rete.

L'ordine in cui chiami precacheAndRoute() o addRoute() è importante. Normalmente consigliamo di chiamarlo all'inizio del file del service worker, prima di registrare eventuali route aggiuntive con registerRoute(). Se prima hai chiamato registerRoute() e questa route corrisponde a una richiesta in entrata, per rispondere verrà utilizzata qualsiasi strategia definita nella route aggiuntiva al posto della strategia cache-first utilizzata da workbox-precaching.

Spiegazione dell'elenco di pre-cache

workbox-precaching prevede un array di oggetti con una proprietà url e revision. Questo array viene a volte indicato come manifest precache:

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 ...
]);

Questo elenco fa riferimento a un insieme di URL, ciascuno con la propria informazione sul "revisione".

Per il secondo e il terzo oggetto dell'esempio precedente, la proprietà revision è impostata su null. Questo perché le informazioni sulla revisione si trovano nell'URL stesso, che è in genere una best practice per gli asset statici.

Il primo oggetto (/index.html) imposta in modo esplicito una proprietà di revisione, ovvero un hash dei contenuti del file generato automaticamente. A differenza delle risorse JavaScript e CSS, in genere i file HTML non possono includere informazioni di revisione negli URL; in caso contrario, i link a questi file sul web non funzionarerebbero ogni volta che i contenuti della pagina venivano modificati.

Passando una proprietà della revisione a precacheAndRoute(), Workbox può sapere quando il file è stato modificato e aggiornarlo di conseguenza.

Workbox include strumenti che consentono di generare questo elenco:

  • workbox-build: questo è un pacchetto di nodi che può essere utilizzato in un'attività gulp o come script di esecuzione npm.
  • workbox-webpack-plugin: gli utenti del webpack possono utilizzare questo plug-in.
  • workbox-cli: la nostra interfaccia a riga di comando può essere utilizzata anche per generare l'elenco di asset e aggiungerli al service worker.

Richieste in entrata di file prememorizzati nella cache

Una cosa che workbox-precaching farà subito è manipolare le richieste di rete in entrata per provare ad associare i file pre-memorizzati nella cache. Ciò è conforme alle pratiche comuni sul web.

Ad esempio, una richiesta per / in genere può essere soddisfatta dal file all'indirizzo /index.html.

Di seguito è riportato l'elenco delle manipolazioni eseguite per impostazione predefinita da workbox-precaching e viene spiegato come puoi alterare tale comportamento.

Ignora parametri URL

Le richieste con parametri di ricerca possono essere modificate per rimuovere valori specifici o tutti i valori.

Per impostazione predefinita, i parametri di ricerca che iniziano con utm_ o corrispondono esattamente a fbclid vengono rimossi, il che significa che una richiesta per /about.html?utm_campaign=abcd verrà soddisfatta con una voce prememorizzata per /about.html.

Puoi ignorare un insieme diverso di parametri di ricerca utilizzando ignoreURLParametersMatching:

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: [/.*/],
  }
);

Indice directory

Per impostazione predefinita, le richieste che terminano con / verranno abbinate a voci con un index.html aggiunto alla fine. Ciò significa che una richiesta in entrata per / può essere gestita automaticamente con la voce prememorizzata nella cache /index.html.

Puoi modificarla in qualcos'altro o disattivarla completamente impostando directoryIndex:

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,
  }
);

Pulisci URL

Se una richiesta non corrisponde alla pre-cache, aggiungeremo .html alla fine per supportare URL "puliti" (ovvero URL "pretty"). Ciò significa che una richiesta come /about verrà gestita dalla voce prememorizzata nella cache per /about.html.

Puoi disattivare questo comportamento impostando cleanUrls:

import {precacheAndRoute} from 'workbox-precaching';

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

Manipolazioni personalizzate

Se vuoi definire corrispondenze personalizzate dalle richieste in arrivo agli asset pre-memorizzati nella cache, puoi farlo utilizzando l'opzione urlManipulation. Si tratta di un callback che restituisce un array di possibili corrispondenze.

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];
    },
  }
);

Utilizzo avanzato

Utilizzo diretto di PrecacheController

Per impostazione predefinita, workbox-precaching configura i listener install e activate per te. Per gli sviluppatori che hanno familiarità con i service worker, questa operazione potrebbe non essere auspicabile se si ha bisogno di un maggiore controllo.

Anziché utilizzare l'esportazione predefinita, puoi utilizzare PrecacheController direttamente per aggiungere elementi alla precache, determinare quando vengono installati questi asset e quando deve essere eseguita la pulizia.

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(...));
});

lettura diretta degli asset pre-memorizzati nella cache

A volte potrebbe essere necessario leggere direttamente un asset pre-memorizzato nella cache, al di fuori del contesto del routing che workbox-precaching può eseguire automaticamente. Ad esempio, potresti voler memorizzare nella cache i modelli HTML parziali che devono essere recuperati e utilizzati durante la creazione di una risposta completa.

In generale, puoi utilizzare l'API Cache Storage per ottenere gli oggetti Response pre-memorizzati nella cache, ma c'è un piccolo aspetto: la chiave cache dell'URL che deve essere utilizzata per la chiamata a cache.match() potrebbe contenere un parametro di controllo delle versioni che workbox-precaching crea e gestisce automaticamente.

Per ottenere la chiave cache corretta, puoi chiamare getCacheKeyForURL(), trasmettere l'URL originale, quindi utilizzare il risultato per eseguire cache.match() nella cache appropriata.

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'));

In alternativa, se tutto ciò che ti serve è l'oggetto Response prememorizzato nella cache, puoi chiamare matchPrecache(), che utilizzerà automaticamente la chiave cache corretta e cercherà nella cache corretta:

import {matchPrecache} from 'workbox-precaching';

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

Pulisci vecchie pre-cache

La maggior parte delle release di Workbox mantiene lo stesso formato per l'archiviazione dei dati pre-memorizzati nella cache e, in genere, le pre-cache create da versioni precedenti di Workbox possono essere utilizzate così come sono dalle release più recenti. Raramente, però, si verifica un cambiamento che provoca un errore nell'archiviazione della pre-cache che richiede agli utenti esistenti di scaricare di nuovo tutti i contenuti e che rende obsoleti i dati precedentemente pre-memorizzati nella cache. (Un tale cambiamento è avvenuto tra le release Workbox v3 e v4.)

Questi dati obsoleti non dovrebbero interferire con le normali operazioni, ma contribuiscono all'utilizzo complessivo della quota di spazio di archiviazione e potrebbe essere più facile per gli utenti eliminarli in modo esplicito. A questo scopo, aggiungi cleanupOutdatedCaches() al service worker o imposta cleanupOutdatedCaches: true se utilizzi uno degli strumenti di creazione di Workbox per generare il service worker.

Utilizzo dell'integrità delle sottorisorse

Alcuni sviluppatori potrebbero richiedere le garanzie aggiuntive offerte dall'applicazione forzata dell'integrità delle sottorisorse durante il recupero degli URL pre-memorizzati nella cache dalla rete.

Puoi aggiungere un'ulteriore proprietà facoltativa denominata integrity a qualsiasi voce del manifest di pre-cache. Se fornito, verrà utilizzato come valore integrity durante la creazione del valore Request utilizzato per compilare la cache. Se viene rilevata una mancata corrispondenza, il processo di prememorizzazione nella cache non andrà a buon fine.

La determinazione delle voci manifest di pre-cache che devono avere proprietà integrity e la determinazione dei valori appropriati da utilizzare non rientrano nell'ambito degli strumenti di creazione di Workbox. Gli sviluppatori che vogliono attivare questa funzionalità devono modificare il manifest precache generato da Workbox per aggiungere autonomamente le informazioni appropriate. L'opzione manifestTransform nella configurazione degli strumenti di creazione di Workbox può aiutarti a:

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.

Tipi

CleanupResult

Proprietà

  • deletedCacheRequests

    stringa[]

InstallResult

Proprietà

  • notUpdatedURLs

    stringa[]

  • updatedURLs

    stringa[]

PrecacheController

Esegue una pre-memorizzazione efficiente degli asset.

Proprietà

  • costruttore

    void

    Crea un nuovo PrecacheController.

    La funzione constructor ha il seguente aspetto:

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

    • opzioni del modello.

      PrecacheControllerOptions facoltativo

  • di strategia

    Strategia

  • attiva

    void

    Elimina gli asset che non sono più presenti nel file manifest pre-cache corrente. Chiama questo metodo dall'evento di attivazione del service worker.

    Nota: questo metodo chiama event.waitUntil() per te, quindi non è necessario chiamarlo autonomamente nei tuoi gestori di eventi.

    La funzione activate ha il seguente aspetto:

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

    • event

      ExtendableEvent

  • addToCacheList

    void

    Questo metodo aggiungerà elementi all'elenco di pre-cache, rimuovendo i duplicati e garantendo che le informazioni siano valide.

    La funzione addToCacheList ha il seguente aspetto:

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

    • entries

      (stringa | PrecacheEntry)[]

      Array di voci da prememorizzare nella cache.

  • createHandlerBoundToURL

    void

    Restituisce una funzione che cerca url nella pre-cache (che prende in considerazione le informazioni di revisione dell'account) e restituisce il valore Response corrispondente.

    La funzione createHandlerBoundToURL ha il seguente aspetto:

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

    • url

      stringa

      L'URL prememorizzato nella cache che verrà utilizzato per cercare Response.

  • getCacheKeyForURL

    void

    Restituisce la chiave cache utilizzata per archiviare un determinato URL. Se l'URL non è stato versione, ad esempio "/index.html", la chiave cache sarà l'URL originale con un parametro di ricerca aggiunto.

    La funzione getCacheKeyForURL ha il seguente aspetto:

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

    • url

      stringa

      Un URL di cui vuoi cercare la chiave cache.

    • returns

      stringa

      L'URL con versione che corrisponde a una chiave cache per l'URL originale o non è definito se l'URL non è pre-cache.

  • getCachedURLs

    void

    Restituisce un elenco di tutti gli URL pre-memorizzati nella cache dal service worker attuale.

    La funzione getCachedURLs ha il seguente aspetto:

    () => {...}

    • returns

      stringa[]

      Gli URL memorizzati nella cache.

  • getIntegrityForCacheKey

    void

    La funzione getIntegrityForCacheKey ha il seguente aspetto:

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

    • cacheKey

      stringa

    • returns

      stringa

      Integrità della sottorisorsa associata alla chiave cache o, se non impostata, non definita.

  • getURLsToCacheKeys

    void

    Restituisce un mapping di un URL pre-memorizzato nella cache alla chiave cache corrispondente, tenendo conto delle informazioni sulla revisione dell'URL.

    La funzione getURLsToCacheKeys ha il seguente aspetto:

    () => {...}

    • returns

      Mappa<stringstring>

      Un URL per il mapping delle chiavi nella cache.

  • installa

    void

    Memorizza nella cache gli asset nuovi e aggiornati. Chiama questo metodo dall'evento di installazione dei service worker.

    Nota: questo metodo chiama event.waitUntil() per te, quindi non è necessario chiamarlo autonomamente nei tuoi gestori di eventi.

    La funzione install ha il seguente aspetto:

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

    • event

      ExtendableEvent

  • matchPrecache

    void

    Questa funzionalità sostituisce direttamente cache.match() con le seguenti differenze:

    • Conosce il nome della pre-cache e verifica soltanto la cache.
    • Ti consente di passare in un URL "originale" senza parametri di controllo delle versioni e cercherà automaticamente la chiave cache corretta per la revisione attualmente attiva di quell'URL.

    ad esempio matchPrecache('index.html') troverà la risposta prememorizzata corretta per il service worker attualmente attivo, anche se la chiave effettiva della cache è '/index.html?__WB_REVISION__=1234abcd'.

    La funzione matchPrecache ha il seguente aspetto:

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

    • richiesta

      stringa | Richiesta

      La chiave (senza parametri di revisione) da cercare nella pre-cache.

    • returns

      Promessa<Risposta>

  • pre-cache

    void

    Aggiunge elementi all'elenco di precache, rimuovendo eventuali duplicati e memorizza i file nella cache" al momento dell'installazione del worker di servizio.

    Questo metodo può essere chiamato più volte.

    La funzione precache ha il seguente aspetto:

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

PrecacheEntry

Proprietà

  • integrità

    stringa facoltativo

  • revisione

    stringa facoltativo

  • url

    stringa

PrecacheFallbackPlugin

PrecacheFallbackPlugin consente di specificare una risposta "di riserva offline" da utilizzare quando una determinata strategia non è in grado di generare una risposta.

Per farlo, intercetta il callback del plug-in handlerDidError e restituendo una risposta pre-memorizzata nella cache, prendendo automaticamente in considerazione il parametro di revisione previsto.

A meno che non passi esplicitamente un'istanza PrecacheController al costruttore, verrà utilizzata l'istanza predefinita. In generale, la maggior parte degli sviluppatori finirà per utilizzare quella predefinita.

Proprietà

  • costruttore

    void

    Crea un nuovo PrecacheFallbackPlugin con l'URL di fallback associato.

    La funzione constructor ha il seguente aspetto:

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

    • config

      oggetto

      • fallbackURL

        stringa

        Un URL pre-memorizzato da usare come riserva se la strategia associata non è in grado di generare una risposta.

      • precacheController

        PrecacheController facoltativo

PrecacheRoute

Una sottoclasse workbox-routing.Route che prende un'istanza workbox-precaching.PrecacheController e la utilizza per abbinare le richieste in entrata e gestire il recupero delle risposte dalla pre-cache.

Proprietà

PrecacheRouteOptions

Proprietà

  • cleanURLs

    booleano facoltativo

  • directoryIndex

    stringa facoltativo

  • ignoreURLParametersMatching

    RegExp[] facoltativo

  • urlManipulation

    urlManipulation facoltativo

PrecacheStrategy

Un'implementazione di workbox-strategies.Strategy progettata specificatamente per funzionare con workbox-precaching.PrecacheController sia per la memorizzazione nella cache sia per il recupero degli asset pre-memorizzati nella cache.

Nota: un'istanza di questa classe viene creata automaticamente durante la creazione di un PrecacheController. In genere non è necessario crearla personalmente.

Proprietà

  • costruttore

    void

    La funzione constructor ha il seguente aspetto:

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

    • opzioni del modello.

      PrecacheStrategyOptions facoltativo

  • cacheName

    stringa

  • fetchOptions

    RequestInit facoltativo

  • matchOptions

    CacheQueryOptions facoltativo

  • plugins
  • copyRedirectedCacheableResponsesPlugin
  • defaultPrecacheCacheabilityPlugin
  • _awaitCompletato

    void

    La funzione _awaitComplete ha il seguente aspetto:

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

    • responseDone

      Promessa<Risposta>

    • handler
    • richiesta

      Richiesta

    • event

      ExtendableEvent

    • returns

      Promise<void>

  • _getResponse

    void

    La funzione _getResponse ha il seguente aspetto:

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

    • returns

      Promessa<Risposta>

  • _handleRecupera

    void

    La funzione _handleFetch ha il seguente aspetto:

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

    • returns

      Promessa<Risposta>

  • _handleInstallazione

    void

    La funzione _handleInstall ha il seguente aspetto:

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

    • returns

      Promessa<Risposta>

  • handle

    void

    Esegui una strategia di richiesta e restituisce un Promise che verrà risolto con un Response, richiamando tutti i callback pertinenti dei plug-in.

    Quando un'istanza di strategia viene registrata con una Workbox workbox-routing.Route, questo metodo viene richiamato automaticamente quando la route corrisponde.

    In alternativa, questo metodo può essere utilizzato in un ascoltatore FetchEvent autonomo passandolo a event.respondWith().

    La funzione handle ha il seguente aspetto:

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

    • opzioni del modello.

      FetchEvent | HandlerCallbackOptions

      Un oggetto FetchEvent o un oggetto con le proprietà elencate di seguito.

    • returns

      Promessa<Risposta>

  • handleAll

    void

    Simile a workbox-strategies.Strategy~handle, ma anziché restituire semplicemente un Promise che si risolve in Response, restituirà una tupla di [response, done] promesse, dove la prima (response) equivale a quanto restituisce handle(), mentre la seconda è una promessa che si risolverà una volta completate tutte le promesse aggiunte a event.waitUntil() nell'ambito dell'esecuzione della strategia.

    Puoi attendere la promessa done per assicurarti che l'eventuale lavoro aggiuntivo eseguito dalla strategia (di solito le risposte nella cache) venga completato correttamente.

    La funzione handleAll ha il seguente aspetto:

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

    • opzioni del modello.

      FetchEvent | HandlerCallbackOptions

      Un oggetto FetchEvent o un oggetto con le proprietà elencate di seguito.

    • returns

      [Promise<Response>, Promise<void>]

      Una tupla di [response, done] promesse che possono essere utilizzate per determinare quando la risposta si risolve e quando il gestore ha completato tutto il suo lavoro.

urlManipulation()

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

Tipo

funzione

Parametri

  • { url }

    oggetto

    • url

      URL

Ritorni

  • URL[]

Metodi

addPlugins()

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

Aggiunge plug-in alla strategia di memorizzazione nella cache.

Parametri

addRoute()

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

Aggiungi un listener fetch al service worker che risponderà alle [richieste di rete]https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers#Custom_responses_to_requests con asset pre-memorizzati nella cache.

Le richieste di asset non prememorizzati nella cache non riceveranno risposta a FetchEvent, consentendo così all'evento di passare ad altri listener di eventi fetch.

Parametri

cleanupOutdatedCaches()

workbox-precaching.cleanupOutdatedCaches()

Aggiunge un listener di eventi activate che eseguirà la pulizia delle pre-cache incompatibili create da versioni precedenti di Workbox.

createHandlerBoundToURL()

workbox-precaching.createHandlerBoundToURL(
  url: string,
)

Funzione helper che chiama PrecacheController#createHandlerBoundToURL sull'istanza PrecacheController predefinita.

Se stai creando la tua PrecacheController, chiama PrecacheController#createHandlerBoundToURL su quell'istanza, invece di utilizzare questa funzione.

Parametri

  • url

    stringa

    L'URL prememorizzato nella cache che verrà utilizzato per cercare Response.

getCacheKeyForURL()

workbox-precaching.getCacheKeyForURL(
  url: string,
)

Recupera un URL e restituisce l'URL corrispondente che potrebbe essere utilizzato per cercare la voce nella precache.

Se viene fornito un URL relativo, la posizione del file del service worker verrà utilizzata come base.

Per le voci pre-memorizzate nella cache senza informazioni di revisione, la chiave cache sarà la stessa dell'URL originale.

Per le voci pre-memorizzate nella cache con informazioni sulla revisione, la chiave cache sarà l'URL originale con l'aggiunta di un parametro di query utilizzato per tenere traccia delle informazioni sulla revisione.

Parametri

  • url

    stringa

    L'URL di cui cercare la chiave cache.

Ritorni

  • stringa | non definita

    La chiave cache che corrisponde all'URL.

matchPrecache()

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

Funzione helper che chiama PrecacheController#matchPrecache sull'istanza PrecacheController predefinita.

Se stai creando il tuo PrecacheController, chiama PrecacheController#matchPrecache su quell'istanza, anziché utilizzare questa funzione.

Parametri

  • richiesta

    stringa | Richiesta

    La chiave (senza parametri di revisione) da cercare nella pre-cache.

Ritorni

  • Promise<Response | undefined>

precache()

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

Aggiunge elementi all'elenco di precache, rimuovendo eventuali duplicati e memorizza i file nella cache" al momento dell'installazione del worker di servizio.

Questo metodo può essere chiamato più volte.

Nota: questo metodo non pubblica nessuno dei file memorizzati nella cache. Solo memorizza i file nella cache. Per rispondere a una richiesta di rete, chiama workbox-precaching.addRoute.

Se hai un singolo array di file da pre-cache, puoi semplicemente chiamare workbox-precaching.precacheAndRoute.

Parametri

precacheAndRoute()

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

Questo metodo aggiungerà voci all'elenco di pre-cache e aggiungerà una route per rispondere agli eventi di recupero.

Questo è un metodo di convenienza che chiama workbox-precaching.precache e workbox-precaching.addRoute in una singola chiamata.

Parametri