javascript - paginas - llamar un div desde otra pagina
Ajax, botón de retroceso y actualizaciones DOM (7)
El uso del URL hash / fragment identifier es una forma bastante común de enlazar / recordar el estado en una aplicación web que se basa en las actualizaciones de Ajax y DOM.
Consulte el proyecto Really Simple History para obtener algunas ideas. Es posible controlar la URL para ver los cambios en el hash, y rsh lo hace, teniendo en cuenta las diferencias del navegador.
Si javascript modifica DOM en la página A, el usuario navega a la página B y luego pulsa el botón Atrás para volver a la página A. Se pierden todas las modificaciones a DOM de la página A y se le presenta la versión original del servidor.
Funciona de esa manera en stackoverflow, reddit y muchos otros sitios web populares. (intente agregar un comentario de prueba a esta pregunta, luego navegue a otra página y presione el botón Atrás para volver - su comentario se "habrá ido")
Esto tiene sentido, sin embargo, algunos sitios web (apple.com, basecamphq.com, etc.) de alguna manera están obligando al navegador a mostrar al usuario el estado más reciente de la página. (vaya a http://www.apple.com/ca/search/?q=ipod , haga clic en el enlace decir descargas en la parte superior y luego haga clic en el botón Atrás - se conservarán todas las actualizaciones de DOM)
¿De dónde viene la inconsistencia?
Esto no tiene nada que ver con el símbolo hash (#).
Si comprueba los encabezados HTTP de Apple, simplemente está almacenando en caché la página.
Facebook recuerda el estado de la página al modificar el identificador de hash en la URL para las solicitudes ajax. Estos cambios se registran en el historial del navegador, por lo que cuando el usuario hace clic en el botón Atrás, el hash cambia a lo que era antes. Entonces, está implícito que necesitarás un poco de Javascript para monitorear el identificador de has y reaccionar cuando el navegador lo cambie. Andreas Blixt tiene un script de monitoreo de hash disponible .
Lo que está buscando es algún tipo de administración de hash de URL. El # en la url es solo para el lado del cliente.
Cuando cambia el estado de la parte posterior con JS, actualiza los datos en el # de la url.
También agrega algún tipo de sondeo que supervisa si el hash ha cambiado y carga el estado de la página en función de los datos nuevos en el hash.
Mira esto:
Para cualquiera que tenga problemas con Rails y esto, tu problema no es bfcache (lo pensé), es la joya turbolinks . Here es cómo eliminarlo.
Con suerte, esto te ahorrará algo de tiempo y golpea tu cabeza contra la pared.
Una respuesta: entre otras cosas, los eventos de descarga causan la invalidación de la memoria caché back / forward .
Algunos navegadores almacenan el estado actual de toda la página web en el llamado "bfcache" o "caché de página". Esto les permite volver a renderizar la página muy rápidamente cuando navegan por los botones Atrás y Adelante, y conserva el estado del DOM y todas las variables de JavaScript. Sin embargo, cuando una página contiene eventos de descarga, esos eventos podrían potencialmente poner la página en un estado no funcional, por lo que la página no se almacena en bfcache y debe volver a cargarse (pero puede cargarse desde la memoria caché estándar) y volver renderizado desde cero, incluido ejecutar todos los controladores de carga. Al regresar a una página a través de bfcache, el DOM se mantiene en su estado anterior, sin necesidad de activar los controladores de carga (porque la página ya está cargada).
Tenga en cuenta que el comportamiento de bfcache es diferente del caché estándar del navegador en lo que respecta a Cache-Control y otros encabezados HTTP. En muchos casos, los navegadores almacenarán en caché una página en bfcache, incluso si de lo contrario no la almacenaría en la memoria caché estándar.
jQuery adjunta automáticamente un evento de descarga a la ventana, por lo que desafortunadamente el uso de jQuery descalificará su página para que no se almacene en el bfcache para preservar el DOM y retroceder / avanzar rápidamente . [Actualización: esto se ha corregido en jQuery 1.4 para que solo se aplique a IE]
- Información sobre el bfcache de Firefox
- Información sobre Safari Page Cache y posibles cambios futuros en cómo funcionan los eventos descargados
- Opera usa navegación de historia rápida
- Chrome no tiene un caché de página ( [1] , [2] )
- Páginas para jugar con manipulaciones DOM y el bfcache:
He intentado que Chrome se comporte como lo hace Safari, y la única forma que he encontrado que funciona es establecer Cache-control: no-store en los encabezados. Esto obliga al navegador a recuperar la página del servidor cuando el usuario presiona el botón Atrás. No es ideal, pero es mejor que mostrar una página desactualizada.