¿Qué persistirá al regresar a través del botón Atrás?

Question

Entiendo que una casilla de verificación permanecerá marcada cuando regrese a una página mediante el botón Atrás. Las clases agregadas usando addClass de jquery, sin embargo, no. ¿Alguien puede ayudarme a entender cuándo algo persistirá o no cuando regrese mediante el botón Atrás? Además, ¿hay alguna manera de guardar el valor de una variable para que pueda usar los valores de la variable para recrear los objetos que no persistieron?

Answer 1

Nada persiste: las clases no persisten porque DOM se regenera, las variables JS no persisten porque el código se vuelve a ejecutar, etc. Al mismo tiempo, las implementaciones del navegador parecen estar muy de acuerdo en mantener el usuario ingresado Forme datos para su conveniencia aunque este comportamiento no forme parte de ninguna especificación oficial.

Si necesita que algunos datos persistan en el lado del cliente, es probable que esté haciendo algo mal desde el punto de vista arquitectónico. ¿Por qué intentas anular el comportamiento del botón "atrás" del navegador para que el usuario vuelva a un estado arbitrario, en lugar de ir a la URL anterior y volver a renderizar la página? Si su aplicación tiene mucha interacción y este comportamiento de botón "atrás" es deseable, puede alejarse de hacer que el usuario navegue entre páginas independientes a favor de realizar solicitudes AJAX y confiar en algo como html5 history api, lo que le permite ejecutar cualquier código arbitrario para poner la página en un estado deseado.

no entra en detalles suficientes sobre lo que realmente se espera que sea tienda - tal vez un localStorage o una alternativa de galletas sería más apropiado

Actualización:

He puesto juntos a fiddle para probar qué tan bien persistirán los datos del formulario al atravesar el historial, y los campos ocultos fueron disponibles para ser procesados ​​por JS; aún no es una buena idea aunque imo

Answer 2

Es más o menos depende del hecho de que maneje o no el hash de la url, es decir, si lo hace, puede persistir todo.

EDITADO:

usted tiene que estar familiarizado con el concepto de aplicación Page único (SPA).

Todo es posible gracias a la capacidad de cambiar location hash property y gestionar el historial del navegador.

Para hacer este sencillo hay un montón de bibliotecas como Sammy.js

Cada vez que tiene hacer una acción que empuja nuevo estado y por lo tanto usted será capaz de manejar presión del botón de retroceso usuario.

Con el fin de conseguir idea de lo que parece, verificación siguiente jsfiddle

En el código que ve la creación de routes:

Sammy(function() { 
    this.get('#:folder', function() { ... }); 
    this.get('#:folder/:mailId', function() { ... }); 
})).run(); 

que especifican hachís, es decir www.mygreatwebsite.com/#inbox/#1 y la forma en que su aplicación va a manejar eso.

Aquí está sucediendo mucho más, por lo que mis enlaces son solo un punto de partida para explorar.

Editado: much simplier example of using sammy.js

Answer 3

Como complemento de las respuestas anteriores, se puede guardar el estado de forma con el estado de vista.

• Understanding ASP.NET View State
• ASP.NET Web Forms - Maintaining the ViewState

ViewState permite ASP.NET para repoblar los campos del formulario en cada devolución de datos al servidor de asegurarse de que una forma no se borra automáticamente cuando el usuario pulsa el botón de enviar.

Answer 4

Los navegadores modernos intentan persistir cada vez más. Firefox experimentó hace varios años con la preservación de todo, incluidos los cambios de nombre de clase, siempre que el servidor indique que la página se puede guardar en el encabezado HTTP y que la página web no ha registrado ningún controlador de eventos onunload. Firefox activa onpageshow y onpagehide cuando el usuario presiona hacia atrás.

https://developer.mozilla.org/en-US/docs/Using_Firefox_1.5_caching https://www.webkit.org/blog/516/webkit-page-cache-ii-the-unload-event/