almacenamiento previo en caché en caja de trabajo

Una función de los service workers es la capacidad de guardar un conjunto de archivos en la caché cuando se instala el service worker. Esto se suele denominar “almacenamiento previo en caché”, ya que estás almacenando contenido en caché antes del service worker que se usa.

La razón principal para hacerlo es que los desarrolladores tienen control sobre la caché, lo que significa que pueden determinar cuándo y cuánto tiempo se almacena en caché un archivo, así como entregarlo al navegador sin ir a la red, lo que significa que se puede usar para crear apps web que funcionen sin conexión.

Workbox simplifica el almacenamiento previo en caché y garantiza que los recursos se descarguen de manera eficiente.

Cómo funciona el almacenamiento previo en caché de la caja de trabajo

Cuando se cargue una app web por primera vez, workbox-precaching analizará todos los recursos que desees descargar, quitará los duplicados y conectará los eventos de service worker relevantes para descargar y almacenar los recursos. Las URLs que ya incluyen información sobre el control de versiones (como un hash de contenido) se usan como claves de caché sin ninguna modificación adicional. Las URLs que no incluyen información sobre el control de versiones tienen un parámetro de consulta de URL adicional agregado a la clave de caché que representa un hash del contenido que Workbox genera durante la compilación.

workbox-precaching hace todo esto durante el evento install del service worker.

Cuando un usuario vuelva a visitar tu app web más adelante y tengas un nuevo service worker con diferentes recursos almacenados en caché previamente, workbox-precaching analizará la lista nueva y determinará qué elementos son completamente nuevos y cuáles de los existentes necesitan actualizarse en función de su revisión. Todos los elementos nuevos o las revisiones de actualización se agregarán a la caché durante el evento install del service worker nuevo.

No se usará este nuevo service worker para responder solicitudes hasta que se active el evento activate. En el evento activate, workbox-precaching verificará si hay elementos almacenados en caché que ya no estén presentes en la lista de URLs actuales y los quitará de la caché.

workbox-precaching realizará estos pasos cada vez que se instale y active tu service worker, lo que garantizará que el usuario tenga los recursos más recientes y solo descargue los archivos que cambiaron.

Cómo entregar respuestas almacenadas previamente en caché

Llamar a precacheAndRoute() o addRoute() creará una ruta que coincida con las solicitudes de las URLs almacenadas en caché previamente.

La estrategia de respuesta que se usa en esta ruta es priorizar la caché: Se usará la respuesta almacenada en caché, a menos que esa respuesta no esté presente (debido a algún error inesperado), en cuyo caso se usará una respuesta de red en su lugar.

El orden en el que llamas a precacheAndRoute() o addRoute() es importante. Por lo general, se recomienda llamarla con anticipación en el archivo de service worker, antes de registrar rutas adicionales con registerRoute(). Si primero llamaste a registerRoute() y esa ruta coincidió con una solicitud entrante, se usará la estrategia que hayas definido en esa ruta adicional para responder, en lugar de la estrategia de priorizar la caché que usa workbox-precaching.

Explicación de la lista de precaché

workbox-precaching espera un array de objetos con una propiedad url y revision. A veces, este array se conoce como un manifiesto de precaché:

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

Esta lista hace referencia a un conjunto de URLs, cada una con su propia información de "revisión".

En el segundo y tercer objeto del ejemplo anterior, la propiedad revision se establece en null. Esto se debe a que la información de revisión está en la URL, lo que suele ser una práctica recomendada para los elementos estáticos.

El primer objeto (/index.html) establece de manera explícita una propiedad de revisión, que es un hash generado automáticamente del contenido del archivo. A diferencia de los recursos de JavaScript y CSS, los archivos HTML, por lo general, no pueden incluir información de revisión en las URLs. De lo contrario, los vínculos a estos archivos en la Web no funcionarán cada vez que cambie el contenido de la página.

Si pasas una propiedad de revisión a precacheAndRoute(), Workbox puede saber cuándo cambió el archivo y actualizarlo según corresponda.

Workbox incluye herramientas que te ayudarán a generar la lista:

  • workbox-build: Este es un paquete de nodos que se puede usar en una tarea de gulp o como una secuencia de comandos de ejecución de npm.
  • workbox-webpack-plugin: Los usuarios de webpack pueden usar este complemento.
  • workbox-cli: Nuestra CLI también se puede usar para generar la lista de elementos y agregarlos a tu service worker.

Solicitudes entrantes de archivos prealmacenados en caché

Una cosa que workbox-precaching hará de inmediato es manipular las solicitudes de red entrantes para tratar de hacer coincidir los archivos prealmacenados en caché. Esto incluye las prácticas comunes en la Web.

Por ejemplo, el archivo en /index.html suele satisfacer una solicitud de /.

A continuación, se muestra la lista de manipulaciones que workbox-precaching realiza de forma predeterminada y cómo puedes alterar ese comportamiento.

Ignorar parámetros de URL

Las solicitudes con parámetros de búsqueda se pueden modificar para quitar valores específicos o quitar todos los valores.

De forma predeterminada, se quitan los parámetros de búsqueda que comienzan con utm_ o que coinciden exactamente con fbclid, lo que significa que una solicitud de /about.html?utm_campaign=abcd se entregará con una entrada almacenada en caché para /about.html.

Puede ignorar un conjunto diferente de parámetros de búsqueda con 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: [/.*/],
  }
);

Índice del directorio

De forma predeterminada, las solicitudes que terminan en / se compararán con entradas que tengan un index.html agregado al final. Esto significa que una solicitud entrante para / se puede controlar automáticamente con la entrada /index.html almacenada en caché.

Puedes cambiar este parámetro de configuración o inhabilitarlo por completo. Para ello, configura 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,
  }
);

URL limpias

Si una solicitud no coincide con el almacenamiento previo en caché, agregaremos .html al final para admitir URLs “limpias” (también conocidas como URLs “bonitas”). Esto significa que una solicitud como /about se controlará mediante la entrada almacenada en caché previamente para /about.html.

Puedes inhabilitar este comportamiento si configuras cleanUrls:

import {precacheAndRoute} from 'workbox-precaching';

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

Manipulaciones personalizadas

Si deseas definir coincidencias personalizadas de solicitudes entrantes a elementos almacenados previamente en caché, puedes hacerlo con la opción urlManipulation. Debe ser una devolución de llamada que muestre un array de coincidencias posibles.

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

Uso avanzado

Cómo usar PrecacheController directamente

De forma predeterminada, workbox-precaching configurará los objetos de escucha install y activate por ti. En el caso de los desarrolladores familiarizados con los service workers, esto puede no ser conveniente si necesitas más control.

En lugar de usar la exportación predeterminada, puedes usar PrecacheController directamente para agregar elementos a la caché previa, determinar cuándo se instalan estos elementos y cuándo se debe realizar la limpieza.

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

Lee recursos prealmacenados en caché directamente

A veces, es posible que debas leer un recurso prealmacenado en caché directamente, fuera del contexto del enrutamiento que workbox-precaching puede realizar automáticamente. Por ejemplo, es posible que desees almacenar previamente en caché plantillas HTML parciales que, luego, deben recuperarse y usarse cuando se construye una respuesta completa.

En general, puedes usar la API de Cache Storage para obtener los objetos Response previamente almacenados en caché, pero existe una arista: la clave de caché de URL que se debe usar cuando se llama a cache.match() puede contener un parámetro de control de versiones que workbox-precaching crea y mantiene automáticamente.

Para obtener la clave de caché correcta, puedes llamar a getCacheKeyForURL(), pasar la URL original y, luego, usar el resultado para realizar una cache.match() en la caché adecuada.

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

Como alternativa, si todo lo que necesitas es el objeto Response prealmacenado en caché, puedes llamar a matchPrecache(), que usará automáticamente la clave de caché correcta y buscará en la caché correcta:

import {matchPrecache} from 'workbox-precaching';

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

Limpia precachés anteriores

La mayoría de las versiones de Workbox mantienen el mismo formato para almacenar datos en caché previamente creados, y el almacenamiento en caché previo creado por versiones anteriores de Workbox normalmente se puede usar tal como está en las versiones más nuevas. Sin embargo, rara vez hay un cambio rotundo en el almacenamiento en caché previo que requiera que los usuarios existentes vuelvan a descargar todo, y que hace que los datos previamente almacenados en caché se vuelvan obsoletos. (ese cambio se produjo entre las versiones de Workbox v3 y v4).

Estos datos obsoletos no deberían interferir en las operaciones normales, pero sí contribuyen al uso general de la cuota de almacenamiento, y puede ser más fácil para los usuarios borrarlos de forma explícita. Para ello, agrega cleanupOutdatedCaches() a tu service worker o configura cleanupOutdatedCaches: true si usas una de las herramientas de compilación de Workbox para generar el service worker.

Usa la integridad de los subrecursos

Es posible que algunos desarrolladores deseen las garantías adicionales que ofrece la aplicación de la integridad de los subrecursos cuando recuperan las URL almacenadas previamente en caché de la red.

Se puede agregar una propiedad opcional adicional llamada integrity a cualquier entrada en el manifiesto de precaché. Si se proporciona, se usará como el valor integrity cuando se construya el Request que se usa para propagar la caché. Si hay un error de coincidencia, el proceso de almacenamiento previo en caché fallará.

Determinar qué entradas del manifiesto de precaché deben tener propiedades integrity y determinar los valores adecuados que se usarán está fuera del alcance de las herramientas de compilación de Workbox. En cambio, los desarrolladores que deseen habilitar esta funcionalidad deben modificar el manifiesto de precaché que genera Workbox para agregar la información adecuada por su cuenta. La opción manifestTransform en la configuración de las herramientas de compilación de Workbox puede ayudar a hacer lo siguiente:

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.

Tipos

CleanupResult

Propiedades

  • deletedCacheRequests

    string[]

InstallResult

Propiedades

  • notUpdatedURLs

    string[]

  • updatedURLs

    string[]

PrecacheController

Se realiza un almacenamiento previo en caché eficiente de los recursos.

Propiedades

  • constructor

    void

    Crea un nuevo PrecacheController.

    La función constructor se ve de la siguiente manera: 

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

    • Opciones

      PrecacheControllerOptions opcional

  • estrategia

    Estrategia

  • activar

    void

    Borra los elementos que ya no están presentes en el manifiesto de precaché actual. Llama a este método desde el evento de activación del service worker.

    Nota: Este método llama a event.waitUntil() por ti, por lo que no necesitas que lo llames en tus controladores de eventos.

    La función activate se ve de la siguiente manera: 

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

    • event

      ExtendableEvent

  • addToCacheList

    void

    Este método agregará elementos a la lista de precaché, quitará duplicados y garantizará que la información sea válida.

    La función addToCacheList se ve de la siguiente manera: 

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

    • entradas

      (string | PrecacheEntry)[]

      Array de entradas para almacenar en caché previamente.

  • createHandlerBoundToURL

    void

    Muestra una función que busca url en la caché previa (tomando la información de revisión de la cuenta) y muestra el Response correspondiente.

    La función createHandlerBoundToURL se ve de la siguiente manera: 

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

    • url

      cadena

      La URL previamente almacenada en caché que se usará para buscar el Response.

  • getCacheKeyForURL

    void

    Muestra la clave de caché usada para almacenar una URL determinada. Si esa URL no tiene versiones, como "/index.html", la clave de caché será la URL original con un parámetro de búsqueda agregado a ella.

    La función getCacheKeyForURL se ve de la siguiente manera: 

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

    • url

      cadena

      Una URL cuya clave de caché deseas buscar.

    • resultados

      cadena

      La URL con versión que corresponde a una clave de caché para la URL original, o no definida si esa URL no se almacena en caché previamente.

  • getCachedURLs

    void

    Muestra una lista de todas las URL que prealmacenaron en caché el service worker actual.

    La función getCachedURLs se ve de la siguiente manera: 

    () => {...}

    • resultados

      string[]

      Las URLs almacenadas previamente en caché.

  • getIntegrityForCacheKey

    void

    La función getIntegrityForCacheKey se ve de la siguiente manera: 

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

    • cacheKey

      cadena

    • resultados

      cadena

      La integridad del subrecurso asociada con la clave de caché, o no definida si no está configurada.

  • getURLsToCacheKeys

    void

    Devuelve una asignación de una URL previamente almacenada en caché a la clave de caché correspondiente, teniendo en cuenta la información de revisión de la URL.

    La función getURLsToCacheKeys se ve de la siguiente manera: 

    () => {...}

    • resultados

      Mapa<stringstring>

      Una URL para almacenar en caché la asignación de claves.

  • Instalar

    void

    Almacena previamente en caché los elementos nuevos y actualizados. Llama a este método desde el evento de instalación del service worker.

    Nota: Este método llama a event.waitUntil() por ti, por lo que no necesitas que lo llames en tus controladores de eventos.

    La función install se ve de la siguiente manera: 

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

    • event

      ExtendableEvent

  • matchPrecache

    void

    Esto actúa como un reemplazo directo de cache.match() con las siguientes diferencias:

    • Solo sabe cuál es el nombre de la caché previa y solo comprueba en ella.
    • Te permite pasar una URL “original” sin parámetros de control de versiones y buscará automáticamente la clave de caché correcta para la revisión actualmente activa de esa URL.

    P. ej.: matchPrecache('index.html') encontrará la respuesta correcta almacenada en caché para el service worker activo actualmente, incluso si la clave de caché real es '/index.html?__WB_REVISION__=1234abcd'.

    La función matchPrecache se ve de la siguiente manera: 

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

    • request

      cadena | Solicitud

      La clave (sin revisar los parámetros) que se debe buscar en la caché previa.

    • resultados

      Promesa<Respuesta>

  • almacenamiento previo en caché

    void

    Agrega elementos a la lista de almacenamiento previo en caché, quita los duplicados y almacena los archivos en la caché cuando se instala el service worker.

    Se puede llamar a este método varias veces.

    La función precache se ve de la siguiente manera: 

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

PrecacheEntry

Propiedades

  • integridad

    cadena opcional

  • Revisión

    cadena opcional

  • url

    cadena

PrecacheFallbackPlugin

PrecacheFallbackPlugin te permite especificar una respuesta de "resguardo sin conexión" para usar cuando una estrategia determinada no pueda generar una respuesta.

Para ello, intercepta la devolución de llamada del complemento handlerDidError y muestra una respuesta almacenada en caché, tomando en cuenta automáticamente el parámetro de revisión esperado.

A menos que pases una instancia de PrecacheController al constructor de manera explícita, se usará la instancia predeterminada. En términos generales, la mayoría de los desarrolladores usarán el valor predeterminado.

Propiedades

  • constructor

    void

    Construye un complemento PrecacheFallbackPlugin nuevo con la URL alternativa asociada.

    La función constructor se ve de la siguiente manera: 

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

    • config

      objeto

      • fallbackURL

        cadena

        Una URL previamente almacenada en caché para usar como resguardo en caso de que la estrategia asociada no pueda generar una respuesta.

      • precacheController

        PrecacheController opcional

PrecacheRoute

Una subclase de workbox-routing.Route que toma una instancia de workbox-precaching.PrecacheController y la usa para hacer coincidir las solicitudes entrantes y controlar la recuperación de respuestas del almacenamiento en caché previo.

Propiedades

PrecacheRouteOptions

Propiedades

  • cleanURLs

    booleano opcional

  • directoryIndex

    cadena opcional

  • ignoreURLParametersMatching

    RegExp[] opcional

  • urlManipulation

    urlManipulation opcional

PrecacheStrategy

Una implementación de workbox-strategies.Strategy diseñada específicamente para funcionar con workbox-precaching.PrecacheController para almacenar en caché y recuperar elementos prealmacenados en caché

Nota: Se crea automáticamente una instancia de esta clase cuando se crea un PrecacheController. Por lo general, no es necesario crearla tú mismo.

Propiedades

  • constructor

    void

    La función constructor se ve de la siguiente manera: 

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

    • Opciones

      PrecacheStrategyOptions opcional

  • cacheName

    cadena

  • fetchOptions

    RequestInit opcional

  • matchOptions

    CacheQueryOptions opcional

  • Complementos

    WorkboxPlugin[]

  • copyRedirectedCacheableResponsesPlugin

    WorkboxPlugin

  • defaultPrecacheCacheabilityPlugin

    WorkboxPlugin

  • _awaitComplete

    void

    La función _awaitComplete se ve de la siguiente manera: 

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

    • responseDone

      Promesa<Respuesta>

    • controlador

      StrategyHandler

    • request

      Solicitud

    • event

      ExtendableEvent

    • resultados

      Promise<void>

  • Respuesta de_get

    void

    La función _getResponse se ve de la siguiente manera: 

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

    • resultados

      Promesa<Respuesta>

  • _handleFetch

    void

    La función _handleFetch se ve de la siguiente manera: 

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

    • resultados

      Promesa<Respuesta>

  • _handleInstall

    void

    La función _handleInstall se ve de la siguiente manera: 

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

    • resultados

      Promesa<Respuesta>

  • identificador

    void

    Realiza una estrategia de solicitud y muestra un Promise que se resolverá con un Response, invocando todas las devoluciones de llamada relevantes del complemento.

    Cuando se registra una instancia de estrategia con un workbox-routing.Route de Workbox, se llama a este método automáticamente cuando la ruta coincide.

    Como alternativa, este método se puede usar en un objeto de escucha FetchEvent independiente pasándolo a event.respondWith().

    La función handle se ve de la siguiente manera: 

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

    • Opciones

      FetchEvent | HandlerCallbackOptions

      Una FetchEvent o un objeto con las propiedades que se indican a continuación

    • resultados

      Promesa<Respuesta>

  • handleAll

    void

    Es similar a workbox-strategies.Strategy~handle, pero en lugar de solo mostrar una Promise que se resuelve en una Response, se mostrará una tupla de promesas [response, done], en la que la primera (response) es equivalente a lo que muestra handle() y la última es una promesa que se resolverá una vez que se complete cualquier promesa que se haya agregado a event.waitUntil().

    Puedes esperar la promesa done para asegurarte de que cualquier trabajo adicional que realiza la estrategia (por lo general, las respuestas en caché) se complete con éxito.

    La función handleAll se ve de la siguiente manera: 

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

    • Opciones

      FetchEvent | HandlerCallbackOptions

      Una FetchEvent o un objeto con las propiedades que se indican a continuación

    • resultados

      [Promise<Response>, Promise<void>]

      Una tupla de [respuesta, hecha] promesas que se pueden usar para determinar cuándo se resuelve la respuesta y cuándo el controlador completó todo el trabajo.

urlManipulation()

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

Tipo

la función

Parámetros

  • { URL }

    objeto

    • url

      URL

Devuelve

  • URL

Métodos

addPlugins()

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

Agrega complementos a la estrategia de almacenamiento previo en caché.

Parámetros

addRoute()

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

Agrega un objeto de escucha fetch al service worker que responderá a las [solicitudes de red]https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers#Custom_responses_to_requests con elementos almacenados en caché previamente.

Solicitudes de elementos que no se almacenan previamente en caché, no se responderá a FetchEvent, lo que permite que el evento se filtre a otros objetos de escucha de eventos fetch.

Parámetros

cleanupOutdatedCaches()

workbox-precaching.cleanupOutdatedCaches()

Se agregó un objeto de escucha de eventos activate que limpiará las cachés previas incompatibles que se crearon con versiones anteriores de Workbox.

createHandlerBoundToURL()

workbox-precaching.createHandlerBoundToURL(
  url: string,
)

Función auxiliar que llama a PrecacheController#createHandlerBoundToURL en la instancia PrecacheController predeterminada.

Si creas tu propia PrecacheController, llama a PrecacheController#createHandlerBoundToURL en esa instancia, en lugar de usar esta función.

Parámetros

  • url

    cadena

    La URL previamente almacenada en caché que se usará para buscar el Response.

Devuelve

getCacheKeyForURL()

workbox-precaching.getCacheKeyForURL(
  url: string,
)

Toma una URL y muestra la URL correspondiente que se podría usar para buscar la entrada en la caché previa.

Si se proporciona una URL relativa, la ubicación del archivo del service worker se usará como base.

Para las entradas almacenadas previamente en caché sin información de revisión, la clave de caché será la misma que la URL original.

En el caso de las entradas almacenadas previamente en caché con información de revisión, la clave de caché será la URL original, con la adición de un parámetro de consulta que se usa para realizar un seguimiento de la información de revisión.

Parámetros

  • url

    cadena

    La URL cuya clave de caché se debe buscar.

Devuelve

  • cadena | no definida

    La clave de caché que corresponde a esa URL.

matchPrecache()

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

Función auxiliar que llama a PrecacheController#matchPrecache en la instancia PrecacheController predeterminada.

Si creas tu propio PrecacheController, llama a PrecacheController#matchPrecache en esa instancia, en lugar de usar esta función.

Parámetros

  • request

    cadena | Solicitud

    La clave (sin revisar los parámetros) que se debe buscar en la caché previa.

Devuelve

  • Promise<Response | undefined>

precache()

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

Agrega elementos a la lista de almacenamiento previo en caché, quita los duplicados y almacena los archivos en la caché cuando se instala el service worker.

Se puede llamar a este método varias veces.

Ten en cuenta que este método no publicará ningún archivo almacenado en caché por ti. Solo almacena en caché previamente los archivos. Para responder una solicitud de red, llama a workbox-precaching.addRoute.

Si tienes un solo array de archivos para almacenar en caché previamente, puedes llamar a workbox-precaching.precacheAndRoute.

Parámetros

precacheAndRoute()

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

Este método agregará entradas a la lista de almacenamiento previo en caché y una ruta para responder a los eventos de recuperación.

Este es un método útil que llamará a workbox-precaching.precache y workbox-precaching.addRoute en una sola llamada.

Parámetros