Estoy averiguando cómo acceder a los datos almacenados en el caché web del trabajador del servicio. Mi trabajador de servicio se ve así:
self.addEventListener('install',(e) => { e.waitUntil( caches.open(astroCacheName).then(c => { return Promise.resolve(c.addAll([ './', './css/normalize.css', './css/main.css', './js/index.js', './js/discovery.js', 'http://localhost:4050/planets', 'http://localhost:4050/stars', 'http://localhost:4050/galaxies' ])) })) }) self.addEventListener('fetch',(e) => { e.respondWith( caches.match(e.request).then(r => { return r || fetch(e.request) })) }) self.addEventListener('activate', function (e) { console.log('activate event') e.waitUntil(caches.keys().then(function (cacheNames) { return Promise.all(cacheNames.map(cache => { if (cache !== astroCacheName) { console.log('Service Worker: Clearing Old Cache') return caches.delete(cache) } })) })) })Donde las tres últimas URLS dentro del evento 'instalar' son una solicitud a mi servidor que responde con JSON al que necesito acceder en el cliente. Están almacenados correctamente en el caché. Entonces, ¿cómo puedo tener acceso a estos datos en el cliente?
Hay dos formas diferentes de "acceder" a las respuestas almacenadas en caché por un trabajador de servicio desde un cliente de window . Uno de ellos es más directo que el otro, y el enfoque específico que utilice debe adaptarse a su caso de uso.
Si hay un trabajador de servicio que controla un cliente de window específico (es decir, una página web), cualquier solicitud de red activará el controlador de eventos de fetch de ese trabajador de servicio y le dará a su trabajador de servicio la oportunidad de generar una respuesta. El controlador de eventos de fetch en el código del trabajador del servicio que proporcionó usa caches.match(e.request) para intentar buscar primero una respuesta almacenada en caché, recurriendo a la red si eso no es posible. Entonces, desde su página web, si llama a fetch('/planets') , la respuesta que obtenga del trabajador del servicio terminará viniendo del caché.
Si hay una falta de caché (dado el controlador de eventos de fetch en su trabajador de servicio actual), o si la solicitud se realiza antes de que el trabajador de servicio haya tomado el control del cliente de la window , la solicitud fetch('/planets') terminará cumpliéndose por la red Eso será más resistente.
La misma API de almacenamiento en caché que está expuesta dentro del alcance global de un trabajador de servicio también está disponible en el alcance global de la window . Esto significa que si ya instaló un trabajador de servicio y ese trabajador de servicio ha llenado sus cachés, puede usar caches.match('/planets') directamente desde el contexto de su página web para obtener el objeto de Response almacenado en caché.
Este enfoque puede ser útil si desea una garantía de que la respuesta que obtiene proviene del caché (a diferencia de una respuesta de la red debido a una falta de caché). La otra cara de esto es que solo obtendrá una respuesta si el trabajador del servicio ya completó la instalación, y no hay respaldo si eso aún no ha sucedido.
Sin embargo, a veces esto es apropiado si, por ejemplo, intenta mostrar solo datos que ya se han almacenado en caché.