Ajax, pulsante Indietro e aggiornamenti DOM

Se javascript modifica il DOM nella pagina A, l'utente passa alla pagina B e quindi preme il pulsante Indietro per tornare alla pagina A. Tutte le modifiche al DOM della pagina A vengono perse e all'utente viene presentata la versione originariamente recuperata dal server.

Funziona in questo modo su stackoverflow, reddit e molti altri siti web popolari. (prova ad aggiungere un commento di prova a questa domanda, quindi vai a una pagina diversa e premi il pulsante Indietro per tornare indietro - il tuo commento sarà "andato")

Ciò ha senso, tuttavia alcuni siti Web (apple.com, basecamphq.com ecc.) In qualche modo costringono il browser a fornire all'utente lo stato più recente della pagina. (vai su http://www.apple.com/ca/search/?q=ipod , fai clic sul link Download in alto e quindi fai clic sul pulsante Indietro: tutti gli aggiornamenti DOM verranno conservati)

da dove viene l'incoerenza?

Una risposta: tra le altre cose, gli eventi di scaricamento causano l'invalidazione della cache di ritorno / inoltro .

Alcuni browser memorizzano lo stato corrente dell'intera pagina web nella cosiddetta "bfcache" o "cache della pagina". Ciò consente loro di rieseguire il rendering della pagina molto rapidamente durante la navigazione tramite i pulsanti Indietro e Avanti e preserva lo stato del DOM e di tutte le variabili JavaScript. Tuttavia, quando una pagina contiene eventi onunload, tali eventi potrebbero potenzialmente mettere la pagina in uno stato non funzionale, quindi la pagina non viene memorizzata nella bfcache e deve essere ricaricata (ma può essere caricata dalla cache standard) e renderizzato da zero, inclusa l'esecuzione di tutti i gestori onload. Quando si torna a una pagina tramite bfcache, il DOM viene mantenuto nel suo stato precedente, senza la necessità di attivare i gestori onload (perché la pagina è già caricata).

Si noti che il comportamento di bfcache è diverso dalla cache del browser standard per quanto riguarda Cache-Control e altre intestazioni HTTP. In molti casi, i browser memorizzeranno una pagina nella cache bfcache anche se non la memorizzerebbero altrimenti nella cache standard.

jQuery allega automaticamente un evento di scaricamento alla finestra, quindi sfortunatamente l'utilizzo di jQuery squalificherà la tua pagina dall'archiviazione nella bfcache per la conservazione del DOM e il ritorno / avanzamento rapido. [Aggiornamento: questo è stato corretto in jQuery 1.4 in modo che si applichi solo a IE]

• Informazioni su Firefox bfcache
• Informazioni sulla cache delle pagine di Safari e possibili modifiche future al funzionamento degli eventi di scaricamento
• Opera utilizza la navigazione rapida della cronologia
• Chrome non dispone di una cache della pagina ( [1] , [2] )
• Pagine per giocare con manipolazioni DOM e bfcache:
  • Questa pagina verrà archiviata nella cache normale
  • Questa pagina non lo farà, ma sarà ancora bfcachged

Ho cercato di convincere Chrome a comportarsi come Safari e l'unico modo in cui ho scoperto che funziona è impostare Cache-control: no-storele intestazioni. Ciò forza il browser a recuperare nuovamente la pagina dal server quando l'utente preme il pulsante Indietro. Non è l'ideale, ma è meglio che vedersi mostrati una pagina obsoleta.

Facebook ricorda lo stato della pagina modificando l'identificatore hash nell'URL per le richieste ajax. Queste modifiche vengono registrate nella cronologia del browser, quindi quando l'utente fa clic sul pulsante Indietro, l'hash cambia a quello che era prima. Quindi è implicito che avrai bisogno di un po 'di Javascript per monitorare l'identificatore has e reagire quando viene modificato dal browser. Andreas Blixt ha uno script di monitoraggio hash disponibile .

Questo non ha nulla a che fare con il simbolo cancelletto (#).

Se controlli le intestazioni HTTP di Apple, sta semplicemente memorizzando la pagina nella cache.

L'utilizzo dell'identificatore hash / frammento dell'URL è un modo abbastanza comune per agganciare / ricordare lo stato in un'applicazione Web che si basa sugli aggiornamenti Ajax e DOM.

Dai un'occhiata al progetto Really Simple History per alcune idee. È possibile monitorare l'URL per le modifiche all'hash, e rsh lo fa, tenendo conto delle differenze del browser.

Per chiunque abbia problemi con Railse questo - il tuo problema non è bfcache (pensavo che lo fosse) - è il turbolinksgioiello. Ecco come rimuoverlo.

Spero che questo ti faccia risparmiare tempo e sbatti la testa contro il muro.

Quello che stai cercando è un qualche tipo di gestione dell'hash degli URL. Il # nell'URL è solo per il lato client.

Quando modifichi lo stato della schiena con JS, aggiorni i dati nel # dell'url.

Inoltre aggiungi un tipo di polling che monitora se l'hash è cambiato e carica lo stato della pagina in base ai nuovi dati nell'hash.

Guarda questo:

http://ajaxpatterns.org/Unique_URLs