Cómo quitar service workers con errores

A veces, se implementa un service worker con errores, y también hay problemas. Por ejemplo, se puede analizar un service worker en el momento del registro y completar la instalación correctamente. Sin embargo, el código con errores de un evento fetch puede hacer que no responda a las solicitudes. lo que da como resultado una página en blanco. Otra posibilidad es que el lenguaje de marcado de la página se almacene en caché de forma agresiva y un service worker solo muestra respuestas inactivas de lenguaje de marcado de una instancia de Cache para visitas posteriores.

Hay muchas formas en que un service worker puede tener consecuencias negativas, y tenerlo en un sitio web de producción es aterrador. Aun así, no todo está perdido. Hay formas de solucionar la situación y volver a la normalidad.

Implementa un service worker no-op

Por lo general, lo único que se necesita para lidiar con un service worker con errores es implementar Un service worker no-op que se instala y se activa de inmediato sin un controlador de eventos fetch:

// sw.js

self.addEventListener('install', () => {
  // Skip over the "waiting" lifecycle state, to ensure that our
  // new service worker is activated immediately, even if there's
  // another tab open controlled by our older service worker code.
  self.skipWaiting();
});

self.addEventListener('activate', () => {
  // Optional: Get a list of all the current open windows/tabs under
  // our service worker's control, and force them to reload.
  // This can "unbreak" any open windows/tabs as soon as the new
  // service worker activates, rather than users having to manually reload.
  self.clients.matchAll({
    type: 'window'
  }).then(windowClients => {
    windowClients.forEach((windowClient) => {
      windowClient.navigate(windowClient.url);
    });
  });
});

Este service worker se instalará y activará de inmediato llamando self.skipWaiting() en el evento install De manera opcional, se puede implementar código adicional en el evento activate para volver a cargar de manera forzada cualquier otra pestaña abierta con un WindowClient que controla el service worker.

Es muy importante que un service worker no-op no contenga un controlador de eventos fetch. Cuando un service worker no controla solicitudes, y esas solicitudes pasan al navegador como si no hubiera un service worker presente. Una vez que se implementa un service worker no-op, el service worker con errores se puede corregir y, luego, implementarlo como una actualización.

Este enfoque funciona en parte porque los navegadores tienen protecciones sólidas contra la colocación de service workers en la caché HTTP, y debido a que realizan comprobaciones de bytes del contenido de un service worker en busca de actualizaciones. Estos valores predeterminados permiten implementar un reemplazo no-op para que un service worker con errores solucione el problema rápidamente.

Medidas adicionales que se deben tomar

La implementación de un service worker no-op debería ser suficiente para neutralizar uno con errores. pero se pueden tomar medidas adicionales si es necesario.

¿Qué pasa si no conoces la URL del service worker anterior?

A veces, se desconoce la URL de un service worker instalado anteriormente. Esto puede deberse a que tiene control de versiones (por ejemplo, contiene un hash en el nombre de archivo). En este caso, puede ser un desafío implementar un service worker no-op que coincida con la URL de cada service worker antiguo que pueda estar registrado. Esto va en contra de las prácticas recomendadas, ya que es probable que los desarrolladores no recuerden todos los hash de cada versión del service worker que se implementó.

Afortunadamente, se envía un encabezado de solicitud HTTP útil con una solicitud para una secuencia de comandos de service worker: Service-Worker En el servidor web, busca este encabezado y, luego, intercepta la solicitud para entregar un service worker no-op en su lugar. Esta función depende del servidor web y de la pila de backend que se usen, por lo que debes consultar la documentación del lenguaje correspondiente para saber cómo hacerlo.

En cuanto a las futuras implementaciones de service worker, usa los nombres de recursos sin versiones (por ejemplo, sw.js). Esto hará que las cosas sean mucho menos complicadas más adelante.

Establecer un encabezado Clear-Site-Data

Algunos navegadores cancelarán el registro de todos los service workers de un origen si se produce un Se estableció el encabezado de respuesta Clear-Site-Data con un valor de 'storage'. Sin embargo, hay un par de cosas que debes tener en cuenta con este enfoque:

• Ten en cuenta que esta acción borrará todo el almacenamiento del origen asociado. Eso incluye localStorage, IndexedDB, sessionStorage y otro almacenamiento (pero no la caché HTTP para el origen).
• Este encabezado no es compatible con todos los navegadores.

Debido a que la compatibilidad con este encabezado no es total, no se puede confiar en ella para solucionar el problema. Por lo tanto, es mejor ver Clear-Site-Data como una medida a tomar además de implementar un service worker no-op.

El daño no es permanente

Puede ser aterrador cuando un service worker con errores interrumpe la experiencia del usuario, especialmente en sitios web grandes y conocidos, pero el daño es temporal y reversible.

Si es necesario implementar un service worker no-op para solucionar la situación tómate un tiempo después del hecho para descubrir exactamente qué salió mal. En el futuro, asegúrate de que un service worker solo controle las solicitudes previstas. Realiza pruebas con frecuencia en la etapa de pruebas y solo implementa actualizaciones cuando sea seguro.