Estoy desarrollando un SPA con un formulario largo de varias páginas. Perder el estado del formulario al recargar es una UX realmente mala. Sobre todo porque la forma es bastante grande.
Dado que se trata de un SPA, el navegador no podrá restaurar el estado del formulario después de una recarga. E incluso si pudiera, es un formulario de varias páginas donde solo se muestra un subconjunto de campos (aunque puede completar entradas ocultas, según pienso).
Podría haber usado el estado del historial para almacenar el estado del formulario actual, pero quiero que el botón Atrás pueda volver a una página de formulario anterior sin borrar el progreso en la página actual.
Podría haber usado sessionStorage, pero necesito almacenar archivos e imágenes como parte de un formulario. + es sincrónico.
Podría haber sincronizado el estado con el servidor, pero no quiero introducir tanta complejidad en el backend, especialmente porque parece que el problema podría resolverse completamente en el cliente.
Estaba pensando en usar IndexedDB. Pero el problema surge cuando el estado del formulario es inaccesible y debe borrarse (por ejemplo, debido a que el usuario cierra una pestaña).
Una forma en que podría pensar en resolverlo es a través del trabajador del servicio, porque tiene la lista de todas las pestañas actualmente abiertas (a través de la API self.clients.matchAll() ), y periódicamente para hacer la recolección de basura en los datos asociados con los que ahora faltan. Identificación del cliente.
Desafortunadamente, es un gran salto de complejidad introducir un soporte de trabajador de servicio adecuado para una aplicación. Preferiría retrasar la introducción de Service Worker hasta que se me requiera implementar primero el soporte fuera de línea.
Me preguntaba si hay diferentes soluciones para el problema de persistencia de formularios en los SPA, que requerirían menos recursos de desarrollo para introducir.
Supongo que ha visto la guía " Si no puedo ejecutar API asíncronas en los estados congelado o terminado, ¿cómo puedo guardar datos en IndexedDB? " en la publicación del blog sobre la API del ciclo de vida de la página , ya que usa un trabajador de servicio conservar los datos es una de las opciones enumeradas allí.
Sin embargo, la otra opción es hacer uso del método commit() en el objeto IDBTransaction , para realizar una operación IDB de solo escritura síncrona efectiva cuando se cierra una pestaña. El artículo menciona que commit() no era ampliamente compatible en ese momento, pero desde que se escribió originalmente, la compatibilidad con los navegadores ha mejorado sustancialmente.
He pensado en innumerables métodos diferentes para emplear tal cosa, pero fue en vano.
pagehide , beforeunload y unload no se activan de manera suficientemente confiable (especialmente en dispositivos móviles).
clients.matchAll() no devuelve clientes descartados (que son abundantes en dispositivos móviles), lo que significa que su sesión aún podría restaurarse, mientras que mi trabajador de servicio habría pensado que se han ido para siempre (y el estado de formulario de recolección de basura).
Probablemente voy a recurrir a la estrategia de desalojo basada en el tiempo (o LRU) para los estados de formulario. Ya sea revisando periódicamente las entradas no utilizadas, por ejemplo, durante un año más o menos, o cuando me estoy acercando a la cuota proporcionada, active el desalojo de LRU.
Idealmente, esto debería resolverse fácilmente al tener una instancia de IndexedDB con ámbito de sesión. Según recuerdo, Jake Archibald mencionó que quiere algo como esto en una plataforma web. Creo que esto debería ser una gran adición y, sinceramente, no muchas personas están discutiendo este problema en la comunidad de desarrollo web (ya que no pude encontrar la respuesta a mi problema (ni discusiones sobre) simplemente buscándolo en Google). Sinceramente, creo que deberíamos esforzarnos por mejorar la UX de esa manera. Tal vez debería molestar a Jake un poco más para que él (y el grupo de trabajo web) sepan que realmente es necesario y... quién sabe... tal vez algún día lo veamos implementado.
En cuanto a ahora, lamentablemente esta es una pregunta sin resolver, ya que todavía no estoy 100% satisfecho con el desalojo basado en el tiempo.