Оновлення Ajax, кнопки повернення та DOM

Якщо javascript змінює DOM на сторінці A, користувач переходить на сторінку B, а потім натискає кнопку назад, щоб повернутися на сторінку A. Усі зміни DOM сторінки A втрачаються, а користувачеві надається версія, спочатку отримана з сервера.

Це працює таким чином на stackoverflow, reddit та багатьох інших популярних веб-сайтах. (спробуйте додати тестове зауваження до цього питання, потім перейдіть на іншу сторінку та натисніть кнопку назад, щоб повернутися - ваш коментар буде "пропав")

Це має сенс, але деякі веб-сайти (apple.com, basecamphq.com тощо) якимось чином змушують браузер обслуговувати останній стан сторінки. (перейдіть за посиланням http://www.apple.com/ca/search/?q=ipod , натисніть посилання Скажіть на завантаження вгорі, а потім натисніть кнопку "назад" - усі оновлення DOM будуть збережені)

звідки випливає неузгодженість?

Одна відповідь: Окрім іншого, події завантаження призводять до недійсності кешу назад / вперед .

Деякі веб-переглядачі зберігають поточний стан всієї веб-сторінки у так званому «bfcache» або «кеші сторінок». Це дозволяє їм дуже швидко відтворювати сторінку під час навігації за допомогою кнопок назад і вперед, а також зберігає стан DOM та всіх змінних JavaScript. Однак, коли на сторінці містяться події завантаження, ці події потенційно можуть перевести її у нефункціональний стан, і тому сторінка не зберігається у bfcache та повинна бути перезавантажена (але може бути завантажена із стандартного кешу) та повторно виводиться з нуля, включаючи запуск усіх оброблювачів завантаження. Повертаючись на сторінку через bfcache, DOM зберігається у попередньому стані, не потребуючи запуску оброблювачів завантаження (оскільки сторінка вже завантажена).

Зауважте, що поведінка bfcache відрізняється від стандартного кешу браузера щодо Cache-Control та інших заголовків HTTP. У багатьох випадках браузери кешуватимуть сторінку в bfcache, навіть якщо в іншому випадку вона не зберігатиме її у стандартному кеші.

jQuery автоматично приєднує подію до вивантаження, тому, на жаль, використання jQuery позбавить вашу сторінку зберігатись у bfcache для збереження DOM та швидкого повернення / перемотування вперед. [Оновлення: це було виправлено у jQuery 1.4, так що воно стосується лише IE]

• Інформація про Firefox bfcache
• Інформація про кеш сторінок Safari та можливі подальші зміни способу роботи подій
• Opera використовує швидку навігацію по історії
• У Chrome немає кешу сторінки ( [1] , [2] )
• Сторінки для гри з DOM маніпуляціями та bfcache:
  • Ця сторінка буде зберігатися у звичайному кеші
  • Ця сторінка не буде, але все одно буде bfcached

Я намагався змусити Chrome поводитись так, як це робить Safari, і єдиний спосіб, який я знайшов, працює - це встановити Cache-control: no-storeзаголовки. Це змушує браузер повторно забирати сторінку з сервера, коли користувач натискає кнопку назад. Не ідеально, але краще, ніж показувати застарілу сторінку.

Facebook запам'ятовує стан сторінки, змінюючи ідентифікатор хешу в URL-адресі для запитів ajax. Ці зміни записуються в історію браузера, тому коли користувач натискає кнопку назад, хеш змінюється на те, що було раніше. Тож мається на увазі, що вам знадобиться Javascript, щоб відстежувати ідентифікатор has і реагувати, коли він змінюється браузером. У Andreas Blixt доступний сценарій хеш-моніторингу .

Це не має нічого спільного з символом хеша (#).

Якщо ви перевірите HTTP-заголовки Apple, це просто кешування сторінки.

Використання ідентифікатора хешу / фрагмента URL - досить поширений спосіб підключення / запам'ятовування стану у веб-програмі, яка спирається на оновлення Ajax та DOM.

Ознайомтеся з проектом « Справді проста історія », щоб отримати деякі ідеї. Можливо відстежувати URL для змін у хеші, і rsh робить це, враховуючи відмінності браузера.

Для всіх, хто Railsзіткнувся з проблемами, і це - ваше питання не bfcache (я думав, що це було) - це turbolinksдорогоцінний камінь. Ось як її видалити.

Сподіваємось, це заощадить вам якийсь час і вдарить головою об стіну.

Що ви шукаєте, це певний тип управління хешем URL-адрес. # В URL-адресі призначений лише для клієнта.

Коли ви змінюєте стан спинки за допомогою JS, то ви оновлюєте дані у # URL-адресі.

Також ви додаєте певний тип опитування, який відстежує, чи змінився хеш, і завантажує стан сторінки, виходячи з нових даних у хеші.

Погляньте на це:

http://ajaxpatterns.org/Unique_URLs