javascript - sirve - ¿Está monitoreando location.hash una solución para el historial en las aplicaciones XHR?

window.history.pushstate example

Question

Como es bien sabido, en las aplicaciones web XHR (también conocido como AJAX) no se construye ningún historial para su aplicación y al hacer clic en el botón de actualización a menudo el usuario se retira de su actividad actual. Me encontré con location.hash (por ejemplo, http://anywhere/index.html#somehashvalue ) para eludir el problema de actualización (use location.hash para informar a su aplicación de su estado actual y use un controlador de carga de página para restablecer ese estado). Es realmente agradable y simple.

Esto me llevó a pensar en usar location.hash para rastrear el historial de mi aplicación. No quiero usar bibliotecas existentes, porque usan iframes, etc. Así que aquí está mi moneda de cinco centavos: cuando la página de la aplicación carga, empiezo esto:

setInterval(
function(){
if (location.hash !== appCache.currentHash) {
appCache.currentHash = location.hash;
appCache.history.push(location.hash);
/* ... [load state using the hash value] ... */
return true;
}
return false;
}, 250
);

( appCache es un objeto predefinido que contiene variables de aplicación) La idea es activar cada acción en la aplicación desde el valor hash. En los navegadores decentes, un cambio de valor hash agrega una entrada al historial, en IE (<= 7) no lo hace. En todos los navegadores, navegar hacia atrás o hacia adelante a una página con otro valor hash no desencadena una actualización de página. Ahí es donde la función intervalled toma el control. Con la función cada vez que se detecta el cambio del valor hash (mediante programación, o haciendo clic atrás o adelante), la aplicación puede tomar las medidas adecuadas. La aplicación puede realizar un seguimiento de su propio historial y debería poder presentar los botones de historial en la aplicación (especialmente para usuarios de IE).

Hasta donde puedo decir, esto funciona con el navegador cruzado y no hay costo en términos de recursos de memoria o procesador. Entonces mi pregunta es: ¿sería esta una solución viable para administrar la historia en XHR-apps? ¿Cuáles son los pros y los contras?

Actualización: porque uso mi framework homebrew, no quería usar uno de los frameworks existentes. Para poder usar location.hash en IE y tenerlo en su historial también, creé un script simple (sí, necesita un iframe) que puede ser útil para usted. Lo publiqué en mi sitio , siéntase libre de usar / modificar / criticarlo.

Answer 1

Creo que te será difícil saber si un usuario avanzó o retrocedió. Digamos que la URL inicia / myapp # page1 para que pueda comenzar a rastrear estados. Luego, el usuario hace algo para crear el url / myapp # page2 Luego, el usuario hace algo para volver a crear el url / myapp # page1. Ahora su historia es ambigua y no sabrá qué eliminar o no.

Los marcos de historial usan iframes para evitar las incoherencias del navegador que usted mencionó. Solo necesita usar iframes en los navegadores que los necesitan.

Otra desventaja es que los usuarios siempre irán por el botón de retroceso de su navegador antes de ir a su botón de retroceso personalizado. Tengo la sensación de que el retraso en la lectura de la historia cada 250 ms también será notable. Tal vez puedas hacer el intervalo aún más apretado, pero entonces no sé si eso hará que las cosas funcionen mal.

He usado el administrador de historial de yui, y aunque no funciona perfectamente todo el tiempo en todos los navegadores (especialmente ie6), ha sido utilizado por muchos usuarios y desarrolladores. El patrón que usan es bastante flexible también.

Answer 2

Hay 3 problemas que tienden a ser combinados por la mayoría de las soluciones:

1. botón de retroceso
2. bookmarkability
3. botón de actualización

Las soluciones basadas en window.location.hash pueden resolver las tres en la mayoría de los casos: el valor en el hash asigna a un estado de la aplicación / página web, por lo que un usuario puede presionar "atrás" / "adelante" / "actualizar" y salta al estado ahora en el hash. También pueden marcar como favorito porque el valor en la barra de direcciones ha cambiado. (Tenga en cuenta que se necesita un iframe oculto para IE relacionado con el hash que no afecta el historial del navegador).

Sin embargo, solo quería señalar que una solución de solo iframe se puede usar sin monitorizar window.location.hash para obtener una solución muy efectiva también.

Google maps es un gran ejemplo de esto. El estado capturado para cada acción del usuario es demasiado grande para colocarlo en window.location.hash (centroide del mapa, resultados de búsqueda, satélite frente a vista de mapa, ventanas de información, etc.). Entonces guardan el estado en una forma incrustada en un iframe oculto. Por cierto, esto resuelve el problema de "actualización" [suave] también. Resuelven la marcabilidad por separado a través del botón "Enlazar a esta página".

Solo pensé que es maravilloso saber / separar los dominios problemáticos en los que estás pensando.

Answer 3

Todo eso es importante para soportar toda la gama de navegadores, pero con suerte la necesidad desaparecerá. IE8 y FF3.6 ambos introdujeron soporte para onhashchange . Me imagino que otros seguirán el ejemplo. Sería una buena idea verificar la disponibilidad de esta funcionalidad antes de usar tiempos de espera o iframes, ya que es realmente la mejor solución actualmente disponible, e incluso funciona en IE.