Ajax, przycisk Wstecz i aktualizacje DOM

Jeśli javascript modyfikuje DOM na stronie A, użytkownik przechodzi do strony B, a następnie naciska przycisk Wstecz, aby wrócić do strony A. Wszystkie modyfikacje DOM strony A zostają utracone, a użytkownikowi zostaje przedstawiona wersja, która została pierwotnie pobrana z serwera.

Działa w ten sposób na stackoverflow, reddit i wielu innych popularnych witrynach. (spróbuj dodać komentarz testowy do tego pytania, a następnie przejdź do innej strony i naciśnij przycisk Wstecz, aby wrócić - Twój komentarz zniknie)

Ma to sens, ale niektóre witryny (apple.com, basecamphq.com itp.) W jakiś sposób wymuszają na przeglądarce udostępnianie użytkownikowi najnowszego stanu strony. (przejdź do http://www.apple.com/ca/search/?q=ipod , kliknij link do pobrania u góry, a następnie kliknij przycisk Wstecz - wszystkie aktualizacje DOM zostaną zachowane)

skąd bierze się niespójność?

Jedna odpowiedź: między innymi zdarzenia rozładowania powodują unieważnienie pamięci podręcznej wstecz / dalej .

Niektóre przeglądarki przechowują aktualny stan całej strony internetowej w tzw. „Bfcache” lub „page cache”. Dzięki temu mogą bardzo szybko ponownie wyrenderować stronę podczas nawigacji za pomocą przycisków Wstecz i Dalej oraz zachować stan DOM i wszystkich zmiennych JavaScript. Jednak gdy strona zawiera zdarzenia onunload, zdarzenia te mogą potencjalnie spowodować, że strona przejdzie w stan niefunkcjonalny, więc strona nie jest przechowywana w bfcache i musi zostać ponownie załadowana (ale może zostać załadowana ze standardowej pamięci podręcznej) i ponownie renderowane od podstaw, w tym uruchamianie wszystkich programów obsługi ładowania. Podczas powrotu do strony przez bfcache, DOM jest utrzymywany w swoim poprzednim stanie, bez konieczności uruchamiania programów obsługi ładowania (ponieważ strona jest już załadowana).

Należy zauważyć, że zachowanie bfcache różni się od standardowej pamięci podręcznej przeglądarki w odniesieniu do Cache-Control i innych nagłówków HTTP. W wielu przypadkach przeglądarki będą buforować stronę w bfcache, nawet jeśli w innym przypadku nie zapisałyby jej w standardowej pamięci podręcznej.

jQuery automatycznie dołącza zdarzenie unload do okna, więc niestety użycie jQuery zdyskwalifikuje twoją stronę z bfcache w celu zachowania DOM i szybkiego przewijania do tyłu / do przodu. [Aktualizacja: zostało to naprawione w jQuery 1.4, więc dotyczy tylko IE]

• Informacje o pliku bfcache przeglądarki Firefox
• Informacje o pamięci podręcznej stron Safari i możliwych przyszłych zmianach w działaniu zdarzeń wyładowania
• Opera używa szybkiej nawigacji po historii
• Chrome nie ma pamięci podręcznej stron ( [1] , [2] )
• Strony do zabawy z manipulacjami DOM i bfcache:
  • Ta strona będzie przechowywana w zwykłej pamięci podręcznej
  • Ta strona nie będzie, ale nadal będzie buforowana

Próbowałem sprawić, aby Chrome zachowywał się tak, jak robi to Safari, i jedynym sposobem, w jaki się przekonałem, jest ustawienie Cache-control: no-storew nagłówkach. Zmusza to przeglądarkę do ponownego pobrania strony z serwera, gdy użytkownik naciśnie przycisk Wstecz. Nie jest to idealne rozwiązanie, ale lepsze niż wyświetlanie nieaktualnej strony.

Facebook zapamiętuje stan strony, modyfikując identyfikator skrótu w adresie URL dla żądań Ajax. Te zmiany są zapisywane w historii przeglądarki, więc gdy użytkownik kliknie przycisk Wstecz, skrót zmieni się na taki, jaki był wcześniej. Zakłada się więc, że będziesz potrzebować JavaScript do monitorowania identyfikatora has i reagowania, gdy zostanie zmieniony przez przeglądarkę. Andreas Blixt ma dostępny skrypt monitorowania skrótu .

Nie ma to nic wspólnego z symbolem krzyżyka (#).

Jeśli chcesz sprawdzić nagłówki HTTP firmy Apple, po prostu buforujesz stronę.

Używanie skrótu / identyfikatora fragmentu adresu URL jest dość powszechnym sposobem przechwytywania / zapamiętywania stanu w aplikacji internetowej, która opiera się na aktualizacjach Ajax i DOM.

Sprawdź projekt Really Simple History , aby znaleźć kilka pomysłów. Możliwe jest monitorowanie adresu URL pod kątem zmian w hashu, a rsh robi to, biorąc pod uwagę różnice między przeglądarkami.

Dla każdego, kto ma problemy z Railsi tym - twoim problemem nie jest bfcache (myślałem, że tak) - to turbolinksklejnot. Oto jak go usunąć.

Miejmy nadzieję, że zaoszczędzi ci to trochę czasu i uderzy głową o ścianę.

To, czego szukasz, dotyczy pewnego rodzaju zarządzania skrótami adresów URL. # W adresie URL jest tylko po stronie klienta.

Kiedy zmieniasz stan tyłu za pomocą JS, aktualizujesz dane w # adresu URL.

Dodajesz również rodzaj odpytywania, który monitoruje, czy hash się zmienił, i ładuje stan strony na podstawie nowych danych w hashu.

Spójrz na to:

http://ajaxpatterns.org/Unique_URLs