Volver a un formulario con datos no significa que se haya enviado

Define la promesa antes de elegir un evento

Hay productos que conservan un borrador y otros que explican que los datos se pierden al salir. Escoge una política coherente con la tarea y comunícala cerca de la acción. No añadas persistencia solo para superar una comprobación técnica: también crea una responsabilidad sobre lo que se guarda y durante cuánto tiempo.

MDN documenta visibilitychange y visibilityState para observar el paso a hidden, por ejemplo al cambiar de pestaña o aplicación. Es una señal para gestionar estado; recibirla no demuestra que un guardado o una petición de red hayan terminado. (MDN Web Docs)

Caso 1: cambiar a otra pestaña y regresar

Rellena un formulario de prueba con texto ficticio y deja un campo a medias. Cambia de pestaña y vuelve. Revisa contenido, foco, validaciones y mensajes de estado. El caso debería permitir distinguir lo que seguía en memoria de lo que la aplicación decidió conservar.

Si hay borrador, comprueba su versión y el momento en que puede mostrarse como guardado. Si la política es mantener datos solo en la pestaña, prueba que el aviso sea comprensible. No conviertas la ausencia de errores en pantalla en evidencia de persistencia.

Caso 2: navegar atrás después de salir

bfcache puede restaurar una página desde memoria, incluido su estado JavaScript. pageshow.persisted permite reconocer esa restauración; pagehide.persisted indica intención de cachear, no garantía. Una vuelta atrás y una carga nueva, por tanto, necesitan comprobaciones diferenciadas. (web.dev / Chrome team)

En el ensayo, sal mediante un enlace y utiliza Atrás. Observa si aparece un formulario recuperado, una confirmación anterior o una pantalla nueva. Decide si los datos relacionados necesitan actualizarse y cómo explicarías al usuario que una confirmación corresponde a una operación previa.

Comprueba especialmente la acción principal: recuperar el aspecto de un formulario no debería disparar otro envío. Si el usuario inicia una nueva acción, el producto necesita tratarla según el estado que conoce el servidor y las reglas de esa tarea.

Caso 3: descarte y recarga

La guía de ciclo de vida advierte de terminaciones y eventos de cierre poco fiables. Freeze, resume y descarte tienen coberturas distintas; no se puede depender de que unload permita guardar al final. Tampoco basta observar hidden para acreditar una persistencia completada. (Chrome for Developers / Philip Walton)

Prepara este caso en los navegadores y dispositivos que hayas definido para la aplicación. Usa las herramientas de prueba apropiadas del navegador y comprueba qué vuelve tras recargar. Documenta versión y condiciones: un resultado en un equipo no acredita todos los demás.

Prueba también la limpieza y la recuperación incompleta

Define qué campos pueden conservarse, quién puede verlos y cómo desaparecen al finalizar o abandonar la tarea. Incluye una comprobación después de corregir un error y otra después de completar la operación. Usa datos ficticios; estas propuestas no constituyen una prueba realizada sobre una aplicación de KIURO.

La elección técnica depende del producto, sus datos y el entorno. Este artículo no recomienda una biblioteca ni estima un coste universal. Una entrega útil es una política de borrador legible, la matriz de recorridos y evidencias de aceptación del servidor. Desde ahí se puede acordar la revisión de una web o ecommerce sin prometer que toda vuelta atrás equivale a un envío.