Solución:
Extraigo lo siguiente de una guía del ciclo de vida del trabajador del servicio:
clientes.clama
Puede tomar el control de los clientes no controlados llamando
clients.claim()dentro de su trabajador de servicio una vez que se activa.Aquí hay una variación de la demostración anterior que llama
clients.claim()en su evento de activación. Deberías ver un gato la primera vez. Digo “debería”, porque esto es sensible al tiempo. Solo verá un gato si el trabajador del servicio se activa yclients.claim()entra en vigor antes de que la imagen intente cargar.Si usa su trabajador de servicio para cargar páginas de manera diferente a como lo harían a través de la red,
clients.claim()puede ser problemático, ya que su trabajador de servicio termina controlando algunos clientes que cargaron sin él.Nota: Veo a mucha gente que incluye a clients.claim () como modelo estándar, pero rara vez lo hago yo mismo. Realmente solo importa en la primera carga, y debido a la mejora progresiva, la página generalmente funciona felizmente sin trabajador de servicio de todos modos.
El trabajador del servicio toma los controles del next page-reload después de su registro. Mediante el uso self.skipWaiting() y self.clients.claim(), puede pedirle al cliente que asuma el control del trabajador del servicio en el first load sí mismo.
p.ej
Digamos que guardo archivos en caché hello.txt, y de nuevo si hago una llamada para hello.txt Habrá llamada al servidor aunque tenga recursos en mi caché. Este es el escenario cuando no uso self.clients.claim(). Sin embargo, al hacer una llamada al servidor hello.txt en las recargas de la siguiente página, estará sirviendo el recurso desde la caché.
Para abordar este problema, tengo que usar una combinación de self.skipWaiting() y self.clients.claim() para que el trabajador del servicio comience a ofrecer contenido tan pronto como se active.
PD:
next page-reload significa volver a visitar la página.
first load indica el momento en que se visita la página por primera vez.