Ajax-, Zurück-Button- und DOM-Updates

Wenn Javascript das DOM auf Seite A ändert, navigiert der Benutzer zu Seite B und drückt dann auf die Schaltfläche Zurück, um zur Seite A zurückzukehren. Alle Änderungen am DOM von Seite A gehen verloren und dem Benutzer wird die Version angezeigt, die ursprünglich vom Server abgerufen wurde.

Dies funktioniert auf Stackoverflow, Reddit und vielen anderen beliebten Websites. (Versuchen Sie, dieser Frage einen Testkommentar hinzuzufügen, navigieren Sie dann zu einer anderen Seite und klicken Sie auf die Schaltfläche "Zurück", um zurückzukehren. Ihr Kommentar ist "weg".)

Dies ist sinnvoll, aber einige Websites (apple.com, basecamphq.com usw.) zwingen den Browser irgendwie dazu, dem Benutzer den neuesten Status der Seite zu liefern. (Gehen Sie zu http://www.apple.com/ca/search/?q=ipod , klicken Sie oben auf den Link "Downloads sagen" und dann auf die Schaltfläche "Zurück" - alle DOM-Updates bleiben erhalten.)

Woher kommt die Inkonsistenz?

Eine Antwort: Unload-Ereignisse führen unter anderem dazu, dass der Back / Forward-Cache ungültig wird .

Einige Browser speichern den aktuellen Status der gesamten Webseite im sogenannten "bfcache" oder "page cache". Auf diese Weise können sie die Seite beim Navigieren über die Schaltflächen Zurück und Vorwärts sehr schnell neu rendern und den Status des DOM und aller JavaScript-Variablen beibehalten. Wenn eine Seite jedoch Onunload-Ereignisse enthält, können diese Ereignisse die Seite möglicherweise in einen nicht funktionsfähigen Zustand versetzen. Daher wird die Seite nicht im bfcache gespeichert und muss neu geladen werden (kann jedoch aus dem Standardcache geladen werden) und erneut von Grund auf neu gerendert, einschließlich der Ausführung aller Onload-Handler. Wenn Sie über den bfcache zu einer Seite zurückkehren, bleibt das DOM in seinem vorherigen Zustand, ohne dass Onload-Handler ausgelöst werden müssen (da die Seite bereits geladen ist).

Beachten Sie, dass sich das Verhalten des bfcache in Bezug auf Cache-Control und andere HTTP-Header vom Standard-Browser-Cache unterscheidet. In vielen Fällen zwischenspeichern Browser eine Seite im bfcache, auch wenn sie sonst nicht im Standardcache gespeichert würden.

jQuery hängt automatisch ein Entladeereignis an das Fenster an. Wenn Sie also jQuery verwenden, wird Ihre Seite leider nicht im bfcache gespeichert, um das DOM zu erhalten und schnell vor- und zurückzuspulen. [Update: Dies wurde in jQuery 1.4 behoben, sodass es nur für den IE gilt.]

• Informationen zum Firefox-Bfcache
• Informationen zum Safari-Seiten-Cache und mögliche zukünftige Änderungen an der Funktionsweise von Entladeereignissen
• Opera verwendet eine schnelle Verlaufsnavigation
• Chrome hat keinen Seiten-Cache ( [1] , [2] )
• Seiten zum Spielen mit DOM-Manipulationen und dem bfcache:
  • Diese Seite wird im regulären Cache gespeichert
  • Diese Seite wird nicht, aber immer noch zwischengespeichert

Ich habe versucht, Chrome dazu zu bringen, sich wie Safari zu verhalten, und die einzige Möglichkeit, die funktioniert, besteht darin, Cache-control: no-storedie Header festzulegen. Dies zwingt den Browser, die Seite erneut vom Server abzurufen, wenn der Benutzer die Zurück-Taste drückt. Nicht ideal, aber besser, als eine veraltete Seite anzuzeigen.

Facebook merkt sich den Seitenstatus, indem es die Hash-ID in der URL für Ajax-Anfragen ändert. Diese Änderungen werden im Browserverlauf aufgezeichnet. Wenn der Benutzer auf die Schaltfläche "Zurück" klickt, ändert sich der Hash auf den vorherigen Wert. Dann wird vorausgesetzt, dass Sie Javascript benötigen, um die Has-ID zu überwachen und zu reagieren, wenn sie vom Browser geändert wird. Andreas Blixt stellt ein Hash-Überwachungsskript zur Verfügung .

Dies hat nichts mit dem Hash-Symbol (#) zu tun.

Wenn Sie die HTTP-Header von Apple überprüfen würden, wird die Seite einfach zwischengespeichert.

Die Verwendung der URL-Hash- / Fragment-ID ist eine weit verbreitete Methode, um den Status in einer Webanwendung zu verknüpfen / zu speichern, die auf Ajax- und DOM-Updates basiert.

Schauen Sie sich das Really Simple History- Projekt für einige Ideen an. Es ist möglich, die URL auf Änderungen am Hash zu überwachen, und rsh führt dies unter Berücksichtigung der Browserunterschiede durch.

Für alle, die Probleme mit Railsund haben - Ihr Problem ist nicht bfcache (ich dachte es wäre) - es ist das turbolinksJuwel. Hier erfahren Sie, wie Sie es entfernen.

Hoffentlich sparen Sie dadurch etwas Zeit und schlagen Ihren Kopf gegen die Wand.

Was Sie suchen, ist für eine Art von URL-Hash-Verwaltung. Das # in der URL ist nur für die Client-Seite.

Wenn Sie den Status der Rückseite mit JS ändern, aktualisieren Sie die Daten in der # der URL.

Außerdem fügen Sie eine Art von Abfrage hinzu, die überwacht, ob sich der Hash geändert hat, und den Status der Seite basierend auf den neuen Daten im Hash lädt.

Schau dir das an:

http://ajaxpatterns.org/Unique_URLs