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 suele denominarse "almacenamiento en caché previo", ya que almacenas en caché el contenido antes de que se use el trabajador de servicio.

El motivo principal para hacerlo es que les brinda a los desarrolladores control sobre la caché, lo que significa que pueden determinar cuándo y durante 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 la API y garantiza que los recursos se descarguen de manera eficiente, lo que quita gran parte del trabajo pesado del almacenamiento previo en caché.

Cómo funciona workbox-precaching

Cuando se carga una app web por primera vez, workbox-precaching analizará todos los recursos que deseas descargar, quitará los duplicados y conectará los eventos del trabajador de servicio relevantes para descargar y almacenar los recursos. Las URLs que ya incluyen información de 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 de control de versiones tienen un parámetro de consulta de URL adicional agregado a su clave de caché que representa un hash de su contenido que Workbox genera en el tiempo de compilación.

workbox-precaching hace todo esto durante el evento install del trabajador de servicio.

Cuando un usuario vuelva a visitar tu app web y tengas un nuevo trabajador de servicio con recursos diferentes almacenados en caché, workbox-precaching analizará la lista nueva y determinará cuáles son completamente nuevos y cuáles de los existentes necesitan actualizarse, según su revisión. Cualquier recurso nuevo o revisión de actualización se agregará a la caché durante el evento install del nuevo trabajador de servicio.

Este nuevo trabajador de servicio no se usará para responder solicitudes hasta que se active su evento activate. En el evento activate, workbox-precaching verificará si hay recursos 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 servicio de trabajo, lo que garantizará que el usuario tenga los recursos más recientes y solo descargue los archivos que cambiaron.

Publicación de respuestas almacenadas en caché

Si llamas a precacheAndRoute() o addRoute(), se creará una ruta que coincida con las solicitudes de 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 no esté presente (debido a algún error inesperado), en cuyo caso se usará una respuesta de red.

El orden en el que llames a precacheAndRoute() o addRoute() es importante. Por lo general, te recomendamos que lo llames al principio del archivo del servicio trabajador, antes de registrar rutas adicionales con registerRoute(). Si primero llamaste a registerRoute() y esa ruta coincidió con una solicitud entrante, se usará cualquier estrategia que hayas definido en esa ruta adicional para responder, en lugar de la estrategia de prioridad de la caché que usa workbox-precaching.

Explicación de la lista de almacenamiento en caché previo

workbox-precaching espera un array de objetos con una propiedad url y revision. A veces, este array se denomina manifiesto de almacenamiento en caché previo:

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".

Para 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 recursos estáticos.

El primer objeto (/index.html) establece de forma 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 sus URLs; de lo contrario, los vínculos a estos archivos en la Web se romperían cada vez que cambie el contenido de la página.

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

Workbox incluye herramientas para ayudarte a generar esta lista:

  • workbox-build: Es un paquete de nodos que se puede usar en una tarea de gulp o como una secuencia de comandos de npm run.
  • 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 recursos y agregarlos a tu trabajador de servicio.

Solicitudes entrantes de archivos almacenados en caché

Una de las acciones que workbox-precaching realizará de forma predeterminada es manipular las solicitudes de red entrantes para intentar hacer coincidir los archivos almacenados en caché. Esto se adapta a las prácticas comunes en la Web.

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

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

Ignora los parámetros de URL

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

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

Puedes 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 de directorios

De forma predeterminada, las solicitudes que terminan en / se compararán con las 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é previamente.

Puedes cambiar este comportamiento a otro o inhabilitarlo por completo si configuras 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,
  }
);

URLs limpias

Si una solicitud no coincide con la caché previa, agregaremos .html al final para admitir URLs "limpias" (también conocidas como URLs "bonitas"). Esto significa que una solicitud como /about será manejada por la entrada almacenada en caché previamente para /about.html.

Para inhabilitar este comportamiento, configura cleanUrls:

import {precacheAndRoute} from 'workbox-precaching';

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

Manipulaciones personalizadas

Si deseas definir coincidencias personalizadas a partir de solicitudes entrantes para recursos almacenados en caché previamente, 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. Para los desarrolladores que estén familiarizados con los trabajadores del servicio, 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 recursos 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(...));
});

Cómo leer recursos almacenados en caché directamente

En ocasiones, es posible que debas leer un recurso almacenado en caché de forma directa, fuera del contexto del enrutamiento que workbox-precaching puede realizar automáticamente. Por ejemplo, es posible que desees almacenar en caché previamente plantillas HTML parciales que, luego, se deben recuperar y usar cuando se construye una respuesta completa.

En general, puedes usar la API de Cache Storage para obtener los objetos Response almacenados en caché previamente, pero hay un inconveniente: la clave de caché de URL que se debe usar cuando se llama a cache.match() podría 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 almacenado en caché previamente, 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');

Cómo limpiar los almacenamientos en caché anteriores

La mayoría de las versiones de Workbox mantienen el mismo formato para almacenar datos almacenados en caché previamente, y las cachés previas creadas por versiones anteriores de Workbox suelen poder usarse tal como están en versiones más recientes. Sin embargo, en raras ocasiones, se produce un cambio drástico en el almacenamiento del almacenamiento en caché previo que requiere que los usuarios existentes vuelvan a descargar todo y que hace que los datos almacenados en caché previamente sean obsoletos. (Este cambio ocurrió entre las versiones 3 y 4 de Workbox).

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

Cómo usar la integridad de subrecursos

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

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

Determinar qué entradas de manifiesto de almacenamiento en caché deben tener propiedades integrity y descubrir los valores adecuados para usar está fuera del alcance de las herramientas de compilación de Workbox. En su lugar, los desarrolladores que quieran habilitar esta funcionalidad deben modificar el manifiesto de almacenamiento en caché previo 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 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

Realiza un almacenamiento en caché previo 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 recursos que ya no están presentes en el manifiesto de almacenamiento en caché actual. Llama a este método desde el evento de activación del trabajador de servicio.

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

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

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

    • evento

      ExtendableEvent

  • addToCacheList

    void

    Este método agregará elementos a la lista de almacenamiento en caché previo, quitará los duplicados y se asegurará de que la información sea válida.

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

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

    • entradas

      (cadena | PrecacheEntry)[]

      Es un array de entradas para almacenar en caché de forma previa.

  • createHandlerBoundToURL

    void

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

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

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

    • url

      string

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

  • getCacheKeyForURL

    void

    Muestra la clave de caché que se usa para almacenar una URL determinada. Si esa URL no tiene control de versión, como "/index.html", la clave de caché será la URL original con un parámetro de búsqueda agregado.

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

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

    • url

      string

      Una URL cuya clave de caché deseas buscar.

    • muestra

      string

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

  • getCachedURLs

    void

    Muestra una lista de todas las URLs que el trabajador de servicio actual prealmacenó.

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

    () => {...}

    • muestra

      string[]

      Las URLs almacenadas en caché previamente

  • getIntegrityForCacheKey

    void

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

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

    • cacheKey

      string

    • muestra

      string

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

  • getURLsToCacheKeys

    void

    Devuelve una asignación de una URL almacenada en caché previamente 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:

    () => {...}

    • muestra

      Map<stringstring>

      Es una URL para almacenar en caché la asignación de teclas.

  • Instalar

    void

    Almacena en caché los recursos nuevos y actualizados. Llama a este método desde el evento de instalación del trabajador de servicio.

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

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

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

    • evento

      ExtendableEvent

  • matchPrecache

    void

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

    • Sabe cuál es el nombre de la caché previa y solo realiza la verificación en esa caché.
    • 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 activa de esa URL.

    P. ej., matchPrecache('index.html') encontrará la respuesta correcta almacenada en caché para el servicio trabajador 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) => {...}

    • solicitud

      Cadena | Solicitud

      Es la clave (sin parámetros de revisión) que se busca en la caché previa.

    • muestra

      Promise<Response>

  • almacenamiento en caché previo

    void

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

    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

    string

PrecacheFallbackPlugin

PrecacheFallbackPlugin te permite especificar una respuesta de "reemplazo sin conexión" que se 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é previamente, teniendo en cuenta automáticamente el parámetro de revisión esperado.

A menos que pases de forma explícita una instancia de PrecacheController al constructor, se usará la instancia predeterminada. En términos generales, la mayoría de los desarrolladores terminarán usando la opción predeterminada.

Propiedades

  • constructor

    void

    Crea un nuevo PrecacheFallbackPlugin con la fallbackURL asociada.

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

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

    • config

      objeto

      • fallbackURL

        string

        Es una URL almacenada en caché que se usa como resguardo si la estrategia asociada no puede generar una respuesta.

      • precacheController

PrecacheRoute

Es 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 de la caché previa.

Propiedades

PrecacheRouteOptions

Propiedades

  • cleanURLs

    booleano opcional

  • directoryIndex

    cadena opcional

  • ignoreURLParametersMatching

    RegExp[] opcional

  • urlManipulation

    urlManipulationOpcional

PrecacheStrategy

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

Nota: Se crea automáticamente una instancia de esta clase cuando se crea un PrecacheController. Por lo general, no es necesario que la crees por tu cuenta.

Propiedades

  • constructor

    void

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

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

    • opciones

      PrecacheStrategyOptions opcional

  • cacheName

    string

  • fetchOptions

    RequestInit opcional

  • matchOptions

    CacheQueryOptions opcional

  • complementos
  • copyRedirectedCacheableResponsesPlugin
  • defaultPrecacheCacheabilityPlugin
  • _awaitComplete

    void

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

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

    • responseDone

      Promise<Response>

    • handler
    • solicitud

      Solicitud

    • evento

      ExtendableEvent

    • muestra

      Promise<void>

  • _getResponse

    void

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

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

    • muestra

      Promise<Response>

  • _handleFetch

    void

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

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

    • muestra

      Promise<Response>

  • _handleInstall

    void

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

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

    • muestra

      Promise<Response>

  • handle

    void

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

    Cuando una instancia de estrategia se registra con un workbox-routing.Route de Workbox, se llama automáticamente a este método 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

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

    • muestra

      Promise<Response>

  • handleAll

    void

    Es similar a workbox-strategies.Strategy~handle, pero en lugar de mostrar solo un Promise que se resuelve en un Response, mostrará una tupla de promesas [response, done], en la que el primero (response) es equivalente a lo que muestra handle() y el segundo es una promesa que se resolverá una vez que se completen las promesas que se agregaron a event.waitUntil() como parte de la ejecución de la estrategia.

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

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

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

    • opciones

      FetchEvent | HandlerCallbackOptions

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

    • muestra

      [Promise<Response>, Promise<void>]

      Es una tupla de promesas [response, done] que se puede usar para determinar cuándo se resuelve la respuesta y cuándo el controlador completó todo su trabajo.

urlManipulation()

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

Tipo

función

Parámetros

  • { url }

    objeto

    • url

      URL

Muestra

  • URL[]

Métodos

addPlugins()

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

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

Parámetros

addRoute()

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

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

No se responderá a las solicitudes de recursos que no se hayan almacenado en caché previamente, lo que permitirá que el evento se transmita a otros objetos de escucha de eventos fetch.FetchEvent

Parámetros

cleanupOutdatedCaches()

workbox-precaching.cleanupOutdatedCaches()

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

createHandlerBoundToURL()

workbox-precaching.createHandlerBoundToURL(
  url: string,
)

Es una función auxiliar que llama a PrecacheController#createHandlerBoundToURL en la instancia predeterminada de PrecacheController.

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

Parámetros

  • url

    string

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

getCacheKeyForURL()

workbox-precaching.getCacheKeyForURL(
  url: string,
)

Recibe 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, se usará la ubicación del archivo del service worker como base.

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

Para las entradas almacenadas en caché previamente 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 hacer un seguimiento de la información de revisión.

Parámetros

  • url

    string

    La URL cuya clave de caché se debe buscar.

Muestra

  • cadena | no definido

    La clave de caché que corresponde a esa URL.

matchPrecache()

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

Es una función auxiliar que llama a PrecacheController#matchPrecache en la instancia predeterminada de PrecacheController.

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

Parámetros

  • solicitud

    Cadena | Solicitud

    Es la clave (sin parámetros de revisión) que se busca en la caché previa.

Muestra

  • Promise<Response | undefined>

precache()

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

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

Se puede llamar a este método varias veces.

Ten en cuenta que este método no publicará ninguno de los archivos almacenados en caché. Solo almacena en caché los archivos de antemano. Para responder a una solicitud de red, llama a workbox-precaching.addRoute.

Si tienes un solo array de archivos para almacenar en caché de antemano, 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 en caché previo y agregará una ruta para responder a los eventos de recuperación.

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

Parámetros