Si bien el ciclo de vida del service worker garantiza un proceso de instalación y actualización predecible, puede hacer que el ciclo de desarrollo local sea un poco más matizado.
En el ciclo de desarrollo local típico, los desarrolladores guardan los cambios en los archivos en un editor de texto, luego cambian al navegador para verificar los cambios y el proceso se repite. Cuando un service worker forma parte de la combinación, este ciclo es prácticamente el mismo, pero puede haber diferencias entre lo que espera el desarrollador y lo que hace el navegador.
Excepciones para el desarrollo local
En general, las API de service worker solo están disponibles en páginas que se transmiten a través de HTTPS,
pero hay excepciones a esta regla en las que pueden estar disponibles a través de HTTP.
Una excepción notable es para las páginas publicadas en más de localhost, lo que funciona bien para el desarrollo local.
Sin embargo, no es inusual que los desarrolladores especifiquen nombres de host locales además de localhost en un archivo de hosts.
Esto es obligatorio en los entornos de desarrollo locales cuando varios proyectos requieren nombres de host diferentes.
En estos casos, bastará con aprovisionar un certificado autofirmado.
Una solución alternativa más conveniente es indicarle al navegador que haga excepciones para las pruebas del service worker.
En el caso de Chrome, ve a chrome://flags/#unsafely-treat-insecure-origin-as-secure y especifica los orígenes inseguros para tratarlos como orígenes seguros.
Firefox ofrece una manera de probar los service workers en orígenes inseguros a través de la configuración devtools.serviceWorkers.testing.enabled en about:config.
Herramientas para el desarrollo de service worker
El desarrollo local con un service worker puede generar comportamientos aparentemente inesperados.
Por ejemplo, supongamos que se implementó una estrategia de solo caché para los recursos estáticos sin versiones o una página "sin conexión" prealmacenada en caché que se espera que se actualice cuando se vuelven a cargar los recursos después de hacer cambios.
Debido a que una versión inactiva de esos elementos siempre se entrega desde una instancia de Cache, aparentemente nunca se actualizan.
Por más frustrante que esto sea, el service worker solo está haciendo lo que se creó, pero hay algunas formas de facilitar las pruebas.
La manera más eficaz de probar un service worker es utilizar ventanas de navegación privada, como las ventanas de incógnito en Chrome o la función de navegación privada de Firefox.
Cada vez que abres una ventana de navegación privada, empiezas de cero.
No hay service workers activos ni instancias Cache abiertas. Esta es la rutina para este tipo de pruebas:
- Abre una ventana de navegación privada.
- Navega a una página que registre un service worker.
- Verifica si el service worker se comporta como esperas.
- Cierra la ventana de incógnito.
- Y todo de nuevo.
Con este proceso, imitas fielmente el ciclo de vida del service worker.
Otras herramientas de prueba disponibles en el panel de la aplicación de Chrome DevTools pueden ayudar, aunque pueden modificar el ciclo de vida del service worker de alguna manera.
El panel de la aplicación tiene un subpanel etiquetado Service Workers, que muestra service workers activos para la página actual. Cada service worker activo se puede actualizar manualmente o incluso cancelar su registro. También hay tres botones de activación en la parte superior que ayudan en el desarrollo.
- Sin conexión simula las condiciones sin conexión. Esto ayuda cuando se prueba si un service worker activo entrega contenido sin conexión.
- Actualizar al volver a cargar: Cuando se activa, se recupera y se reemplaza el service worker actual cada vez que se vuelve a cargar la página.
- La opción Omitir para la red, cuando se activa, elude cualquier código en el evento
fetchde un service worker y siempre obtiene contenido de la red.
Estos son botones de activación útiles, en particular Bypass for network, que es excelente cuando desarrollas un proyecto con un service worker activo, pero también quieres asegurarte de que la experiencia funcione como se espera sin un service worker.
Firefox tiene un panel de aplicación similar en sus herramientas para desarrolladores, pero la funcionalidad se limita a mostrar qué service workers están instalados, así como a la capacidad de cancelar manualmente el registro de cualquier service worker activo para la página actual. Es igual de útil, pero requiere más esfuerzo manual en el ciclo de desarrollo local.
Cambiar y volver a cargar
Cuando desarrollas de forma local con un service worker activo sin la necesidad de usar la funcionalidad que proporciona la opción actualizar con actualización o omitir para la red, también es útil mantener presionada la tecla Mayúsculas y presionar el botón para actualizar.
Esto se denomina actualización forzada, que omite la caché HTTP de la red. Cuando un service worker está activo, una actualización forzada también omite el service worker por completo.
Esta funcionalidad es excelente si no hay certeza acerca de si una estrategia de almacenamiento en caché en particular funciona según lo previsto, y es útil tomar todo de la red para comparar comportamientos con y sin un service worker. Mejor aún, es un comportamiento específico, así que todos los navegadores compatibles con service workers lo observarán.
Inspecciona el contenido de la caché
Es difícil saber si una estrategia de almacenamiento en caché funciona según lo previsto si no se puede inspeccionar la caché.
Claro, la caché podría inspeccionarse en el código, pero es un proceso que involucra depuradores o sentencias console cuando una herramienta visual sería más adecuada para la tarea.
El panel Application de las Herramientas para desarrolladores de Chrome ofrece un subpanel para inspeccionar el contenido de las instancias de Cache.
Este subpanel facilita el desarrollo de service worker, ya que ofrece funcionalidades como las siguientes:
- Visualiza los nombres de las instancias de
Cache. - La capacidad de inspeccionar el cuerpo de la respuesta de los elementos almacenados en caché y sus encabezados de respuesta asociados.
- Expulsa uno o más elementos de la caché o incluso borra instancias
Cachecompletas.
Esta interfaz gráfica de usuario facilita la inspección de cachés del service worker para ver si se agregaron, actualizaron o quitaron elementos de la caché del service worker. Firefox ofrece su propio visor de caché con una funcionalidad similar, aunque se encuentra en un panel de Almacenamiento independiente.
Simula una cuota de almacenamiento
En los sitios web con muchos recursos estáticos grandes (como imágenes de alta resolución), es posible alcanzar las cuotas de almacenamiento. Cuando esto sucede, el navegador expulsará de la caché los elementos que considere obsoletos o que, de otro modo, merecen sacrificarse para hacer lugar a nuevos recursos.
Lidiar con las cuotas de almacenamiento debería ser parte del desarrollo de service worker, y Workbox facilita ese proceso que administrarlo por tu cuenta. Sin embargo, con o sin Workbox, simular una cuota de almacenamiento personalizada para probar la lógica de administración de caché podría ser una buena idea.
El panel Application de las Herramientas para desarrolladores de Chrome tiene un subpanel Storage que ofrece información sobre la cantidad de almacenamiento actual que usa la página. También permite que se especifique una cuota personalizada en megabytes. Cuando esté vigente, Chrome aplicará la cuota de almacenamiento personalizada para que se pueda probar.
Por cierto, este subpanel también contiene el botón Borrar datos de sitios y diversas casillas de verificación asociadas con los elementos que se deben borrar al hacer clic en el botón.
Entre estos elementos, se encuentran las instancias de Cache abiertas y la capacidad de cancelar el registro de los service workers activos que controlen la página.
Desarrollo más sencillo, mejor productividad
Cuando los desarrolladores no tienen obligaciones, pueden trabajar con mayor confianza y ser más productivos. El desarrollo local con un service worker puede tener matices, pero no tiene por qué ser difícil. Con estas sugerencias y trucos, el desarrollo con un service worker activo debería ser mucho más transparente y predecible, lo que mejoraría la experiencia del desarrollador.