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 tenga más matices.
En el ciclo típico de desarrollo local, los desarrolladores guardan los cambios en los archivos en un editor de texto luego cambia al navegador para verificar los cambios y el proceso se repetirá. Cuando un service worker está en la mezcla, el ciclo es casi el mismo pero puede haber diferencias entre lo que espera el desarrollador y lo que hace el navegador.
Excepciones del desarrollo local
En general, las APIs 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 notable excepción son las páginas publicadas para más de localhost, que funcionan bien para el desarrollo local.
Sin embargo, es normal que los desarrolladores especifiquen nombres de host locales además de localhost en un
archivo host.
Esto es necesario 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 indicar al navegador que haga excepciones para las pruebas de service worker.
Para Chrome, navega a chrome://flags/#unsafely-treat-insecure-origin-as-secure
y especifican orígenes inseguros para tratar como orígenes seguros.
Firefox ofrece una forma de probar service workers en orígenes no seguros a través de la configuración devtools.serviceWorkers.testing.enabled en about:config.
Recursos para el desarrollo de service workers
El desarrollo local con un service worker en la combinación puede generar comportamientos aparentemente inesperados.
Por ejemplo, supongamos que se implementó una estrategia de solo caché para los elementos estáticos sin control de versiones o una estrategia de almacenamiento en caché previa que indica que no tienes conexión que se espera que se actualice cuando se vuelva a cargar la página 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!
Lo frustrante es que el service worker
solo hace para lo que fue diseñado
pero existen algunas formas
de facilitar las pruebas.
Sin duda, la forma más eficaz de probar un service worker es confiar en las ventanas de navegación privada, como las ventanas de incógnito de Chrome,
o la función Navegación privada de Firefox.
Cada vez que abres una ventana de navegación privada, vuelves a empezar.
No hay service workers activos ni instancias de Cache abiertas. La rutina para este tipo de pruebas es la siguiente:
- 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 Herramientas para desarrolladores de Chrome puede ser útil, aunque pueden modificar el ciclo de vida del service worker de algunas maneras.
El panel de la aplicación tiene un subpanel etiquetado como Service Workers, que muestra los service workers activos para la página actual. Cada service worker activo se puede actualizar manualmente o incluso cancelar el registro por completo. En la parte superior, también hay tres botones de activación que ayudan en el desarrollo.
- Sin conexión simula condiciones sin conexión. Esto es útil cuando se prueba si un service worker activo entrega contenido sin conexión.
- Update on reload: Cuando se activa esta opción, se recupera y se reemplaza el service worker actual cada vez que se vuelve a cargar la página.
- Cuando se activa la opción Omitir para la red, elude cualquier código del evento
fetchde un service worker y siempre obtiene contenido de la red.
Estos son botones de activación útiles, en especial Bypass for network, lo que es muy útil cuando se desarrolla un proyecto con un service worker activo, sino también asegurarse de que la experiencia funcione como se espera sin un service worker.
Firefox tiene un panel de aplicaciones similar en sus herramientas para desarrolladores, pero la funcionalidad se limita a mostrar qué service workers están instalados, así como cancelar manualmente el registro de cualquier service worker activo en la página actual. Es igual de útil, pero requiere de un mayor esfuerzo manual en el ciclo de desarrollo local.
Mayúsculas y volver a cargar
Cuando desarrollas localmente con un service worker activo sin la necesidad de la funcionalidad que proporciona la actualización al actualizar o la omisión para la red, también es útil mantener presionada la tecla Mayús y presionar el botón de actualización.
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 por completo al service worker.
Esta funcionalidad es excelente cuando hay incertidumbre sobre si una estrategia de almacenamiento en caché en particular está funcionando según lo previsto, y es útil tomar todo desde la red para comparar comportamientos con y sin un service worker. Mejor aún, es un comportamiento específico, por lo 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 la caché no se puede inspeccionar.
Por supuesto, podría inspeccionarse la caché en el código.
pero se trata de un proceso que incluye 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 workers, que ofrece funcionalidades como las siguientes:
- Consulta 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 completas de
Cache.
Esta interfaz gráfica de usuario facilita la inspección de cachés de service worker para ver si se agregaron, actualizaron o quitaron por completo elementos de una caché de service worker. Firefox ofrece su propio visualizador de caché con una funcionalidad similar, aunque se encuentra en un panel Almacenamiento separado.
Simula una cuota de almacenamiento
En 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 inactivos o que de otro modo deben sacrificar para liberar espacio para nuevos recursos.
Manejar las cuotas de almacenamiento debe ser parte del desarrollo de service workers y Workbox simplifica 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 la 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 el porcentaje de la cuota de almacenamiento actual que usa la página. También permite que una cuota personalizada se especifique 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 Clear site data y una serie de casillas de verificación asociadas que indican qué se debe borrar cuando se hace 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 controlan la página.
Desarrollo más sencillo y mayor productividad
Cuando los desarrolladores no tienen restricciones, pueden trabajar con más confianza y aumentar su productividad. El desarrollo local con un service worker puede tener matices, pero no tiene por qué ser doloroso. Con estas sugerencias y trucos, el desarrollo con un service worker activo debería ser mucho más transparente y predecible, lo que genera una mejor experiencia para los desarrolladores.