Galería de Imágenes con PWA
Estrategia Caché Primero e Intercepción de Peticiones
Maquetación
La galería se divide visualmente en dos contenedores principales, el primero tiene la imagen principal y el segundo tiene las imágenes en pequeño.
Diseño
Para ajustar el diseño usamos cajas flexbox.
Lógica de la Galería
Creamos una función que nos permita reemplazar las imágenes de la galería y controlar cuándo se le da clic a alguna imagen pequeña.
Lógica de la Aplicación
Creamos una función que determine la lógica de la aplicación, que consiste en registrar el service worker y obtener la lista de imágenes que serán colocadas en la galería.
Service Worker — Instalación
En la instalación creamos una función de instalación y esperamos a que finalice, agregamos al caché los archivos de estilos y el logo.
Service Worker — Activación
En la activación creamos una función de activación que borre las versiones previas del caché (las que no coincidan con la actual).
Service Worker — Interceptar Peticiones
Este es uno de los códigos más importantes, aquí interceptamos las peticiones que se realizan. En la estrategia “Caché Primero” determinamos que si el recurso ya se encuentra en el caché lo devolvamos, es decir, si la petición es hacia los estilos, el manifiesto, el logo o la página principal, devolveremos estos recursos. En caso contrario intentaremos descargar la petición, si esta se descarga correctamente enviaremos la respuesta obtenida en la descarga. En caso de que falle la petición (error de conexión), simularemos una respuesta que contenga el logo de la aplicación, para mantener una funcionalidad offline y no dejar la galería vacía.
Proyecto Completo
El proyecto completo se encuentra disponible en codesandbox.io.
index.html— Contiene la maquetación, la referencia a los estilos y al archivo de lógica de la aplicación.style.css— Contiene los estilos de diseño usados por la galería.app.js— Contiene la lógica de la galería y la lógica de la aplicación. Aquí se activa el service worker.worker.js— Contiene los eventos de instalación, activación e intercepción de peticiones.
Conclusiones
Al construir aplicaciones web muchas veces usaremos peticiones web a nuestros servidores o servidores externos para extraer la información de la aplicación, como la lista de imágenes, la información del usuario, los detalles de un producto, el carrito de compras, enviar un formulario capturado, etc. Todas estas peticiones serán procesadas fuera de la aplicación, por lo que corren el riesgo de fallar eventualmente, ya sea que estemos sin conexión, o puede que el servidor no responda. En cualquier caso, la experiencia del usuario se verá limitada si no tenemos en cuenta alguna estrategia para brindar una experiencia fuera de línea (offline / sin conexión a internet). Y es aquí la importancia de las aplicaciones web progresivas, cuyo poder radica principalmente en el Service Worker y las estrategias de caché que ideemos.
El service worker tiene el objetivo principal de almacenar recursos en caché, borrar recursos del caché e interceptar las peticiones web a recursos externos, para así idear estrategias que nos permitan resolver las eventualidades que puedan ocurrir, por ejemplo, si se pierde la conexión a internet o las peticiones al servidor fallan en general.
Una estrategia muy común es el “Caché Primero” que determina enviar recursos solicitados si ya se encuentran en caché, aquí debemos tener cuidado que dichos recursos no se actualicen seguido y puedan ser consumidos sin importar que haya pasado algún tiempo. En caso contrario, siempre podremos crear tareas que actualicen periódicamente el contenido, por ejemplo, un catálogo de promociones, una lista de clientes o proveedores, etc.
Finalmente, debemos dominar lo más posible las respuestas simuladas, ya que muchas veces tendremos que devolver datos ficticios generados en ese momento, para no incrementar el caché y generar una experiencia buena.
Piensa en el siguiente proyecto. Se trata de un formulario que está siendo capturado por el usuario y enviado al servidor, eventualmente el servidor recibe el formulario y todo listo. Sin embargo, puede ocurrir que el servidor falle y el formulario no logre enviarse. En tal caso, deberemos almacenar el formulario provisionalmente en caché bajo un identificador y devolverle a la aplicación una respuesta simulada, indicando cuál es el identificador del formulario y que está pendiente de enviarse. La aplicación deberá enviar nuevamente el formulario ya sea manualmente, cuándo se vuelva a tener conexión a internet o bajo alguna estrategia.
Intenta resolver dicho proyecto y comenta que te ha parecido o si has tenido algún problema al realizarlo.
