recargar - Mantener el historial de cambios hash/anchor en JavaScript
window history replacestate({} (5)
Actualmente estoy implementando una biblioteca de JavaScript que realiza un seguimiento del historial de cambios en la parte de hash en la barra de direcciones. La idea es que puede mantener un estado en la parte hash y luego usar el botón Atrás para volver al estado anterior.
En la mayoría de los navegadores recientes, esto es automático y solo tiene que sondear la propiedad location.hash para los cambios (en IE8 ni siquiera tiene que hacer eso; simplemente adjunte una función al evento onhashchange ).
Lo que me pregunto es , ¿qué métodos diferentes existen para realizar un seguimiento de la historia? He implementado una funcionalidad que ha sido probada para funcionar en Internet Explorer 6/7/8, Firefox y Chrome, pero ¿qué pasa con otros navegadores? Aquí están las formas en que actualmente mantengo la historia:
Edición : vea mi respuesta a continuación para obtener una descripción de los distintos navegadores.
Basado en el esfuerzo que has puesto en esto, asumo que has visto YUI Browser History Manager , pero por si acaso ...
Hacen un buen resumen de su implementación, y me parece que su código fuente es muy legible.
Esto es lo que dice acerca de la ópera
* location.hash is a bit buggy on Opera. I have seen instances where
* navigating the history using the back/forward buttons, and hence
* changing the URL, would not change location.hash. That''s ok, the
* implementation of an equivalent is trivial ... more below
Buscando en la fuente, también encontré algunos alojamientos para Safari 1.xy 2.0. Parece que estarías interesado en ello.
Espero que ayude.
En primer lugar, gracias a ustedes que respondieron! =)
Ahora he investigado mucho más y creo que estoy satisfecho con mi implementación. Aquí están los resultados de mi investigación.
En primer lugar, mi biblioteca de Hash terminada . Es una biblioteca independiente sin dependencias. Tiene dos funciones: Hash.init(callback, iframe) y Hash.go(newHash) . La función de devolución de llamada se llama siempre que el hash cambia con el nuevo hash como su primer argumento, y como segundo argumento, un indicador que indica si la devolución de llamada se llama debido al estado inicial ( true ) o un cambio real al hash ( false ).
Hash.js (licencia MIT)
También hice un plugin de jQuery para que sea más fácil de usar. Agrega un evento de hashchange global también. Vea el ejemplo en el código fuente para saber cómo usarlo.
jquery.hash.js (licencia MIT)
Para verlos en uso, vaya a mi página "reino" de JavaScript:
Internet Explorer 8
Smooooth cruisin ''! Simplemente pegue uno o ''ellos en eventos de onhashchange al objeto de window (usando attachEvent ) y obtenga el valor de location.hash en el controlador de eventos.
No importa si el usuario hace clic en un enlace con un hash, o si establece el hash mediante programación; La historia se guarda perfectamente.
Chrome, Firefox, Safari 3+, Opera 8+
Crucero suave! Solo setInterval cambios en la propiedad location.hash usando setInterval y una función.
La historia funciona perfectamente. Para Opera, configuro history.navigationMode como ''compatible'' . Para ser honesto, no estoy seguro de lo que hace, lo hice por recomendación de un comentario en el código YUI.
Nota : Opera necesita algunas pruebas adicionales, pero hasta ahora me ha funcionado bien.
¡Bonificación sorpresa! (¡¿Puede ser ?!) Resulta que Firefox (solo confirmado en 3.5+) decodifica la propiedad location.hash , por lo que puede desencadenar un evento hashchange dos veces (primero para la versión codificada y luego para la versión no codificada). Nueva versión de mi biblioteca Hash.js que toma esto en cuenta al usar la propiedad location.href lugar (cambios proporcionados por Aaron Ogle).
Internet Explorer 6, 7
Ahora se vuelve más desagradable. El historial de navegación en versiones anteriores de Internet Explorer ignora los cambios de hash. Para solucionar esto, la solución comúnmente aceptada es crear un iframe y establecer su contenido al nuevo hash. Esto crea una nueva entrada en el historial de navegación. Cuando el usuario vuelve, esto cambia el contenido del iframe a su contenido anterior. Al detectar el cambio de contenido, puede obtenerlo y configurarlo como el hash activo.
La verificación de cambios en la propiedad location.hash aún es necesaria para realizar cambios manuales en la dirección actual. Tenga cuidado con las peculiaridades que he mencionado a continuación, sin embargo.
Si bien esta solución parece ser la mejor que existe, aún no es perfecta en Internet Explorer 6, lo cual es un tanto peculiar sobre los botones de avance / retroceso. Sin embargo, Internet Explorer 7 funciona bien.
Sorpresa extra bonus # 1! En Internet Explorer 6, siempre que hay un signo de interrogación en el hash, este se extrae y se coloca en la propiedad location.search . Se elimina de la propiedad location.hash . Sin embargo, si hay una cadena de consulta real, location.search contendrá esa en su lugar, y solo podrá obtener todo el hash verdadero analizando la propiedad location.href .
Sorpresa extra bonus # 2! Si se establece la propiedad location.search , todos los caracteres # subsiguientes se eliminarán de la propiedad location.href (y location.hash ). En Internet Explorer 6, esto significa que siempre que haya un signo de interrogación en la ruta o el hash, experimentará esta peculiaridad. En Internet Explorer 7, esta peculiaridad solo se produce cuando hay un signo de interrogación en la ruta. ¿No te encanta la consistencia en Internet Explorer?
Sorpresa extra bonus # 3! Si otro elemento en la página tiene el mismo id que el valor de un hash, ese hash arruinará totalmente el historial. Por lo tanto, la regla de oro es evitar los hashes con la misma ID que cualquier elemento de la página. Si los hashes se generan dinámicamente y pueden chocar con identificadores, considere usar un prefijo / sufijo.
Otros navegadores
A menos que tenga una base de usuarios fuera de lo común, no tendrá que admitir más navegadores. Los navegadores que no figuran en la lista anterior están en la categoría de uso <1%.
GWT proporciona gestión de la historia. También es una parte integral de su marco de MVP. También han mejorado la historia API con lugares y actividades.
No estoy seguro de entender completamente sus necesidades, pero he usado la biblioteca Really Simple History ( http://code.google.com/p/reallysimplehistory/ ) para implementar algo similar. Puedes verlo aquí: http://whiteoak.sourceforge.net/
No he visto nada sobre lo que voy a decir en ningún lugar, así que pensé en compartirlo y ver qué tan conocido es.
En IE (solo verificado en IE7), el historial con el hash funciona correctamente cuando hay un elemento de página en la pantalla con un id igual al hash. Por ejemplo, piense en una tabla de contenido (TOC) en una página wiki. Cada enlace en el TOC se enlaza con un hash de un id o elemento de nombre de ancla en algún lugar de la página:
<div id="TOC">
<a id="SampleHeaderLink" href="#SampleHeader">Sample Header</a>
</div>
<h2 id="SampleHeader">Sample Header</a>
Así que cuando se hace clic en SampleHeaderLink, la configuración predeterminada del navegador IE es navegar a SampleHeader y registrar el estado en el historial. El uso del botón de retroceso y el botón de avance funciona como se espera.
Sin embargo, si el div SampleHeader no existe en la página, el navegador solo registra el cambio de URL, pero no crea un nuevo estado para él.
De nuevo, esto solo se verifica en IE7. Y no sé qué tan común es esta información, pero nunca encontré nada relacionado cuando estaba navegando para solucionar este problema en mi propia aplicación.