Является ли мониторинг location.hash решением для истории в XHR-приложениях?

Как известно, в веб-приложениях XHR (aka AJAX) история для вашего приложения не создается, и нажатие кнопки обновления часто перемещает пользователя из его текущей активности. Я наткнулся на location.hash(например, http://anywhere/index.html#somehashvalue), чтобы обойти проблему обновления (используйте location.hash, чтобы сообщить вашему приложению о текущем состоянии и использовать обработчик нагрузки страницы до состояния reset). Это действительно хорошо и просто.

Это заставило меня задуматься об использовании location.hash для отслеживания истории моего приложения. Я не хочу использовать существующие библиотеки, потому что они используют iframe и т.д. Итак, вот мой никель и копейка: при загрузке страницы приложения я запускаю это:

setInterval(
       function(){
           if (location.hash !== appCache.currentHash) {
               appCache.currentHash = location.hash;
               appCache.history.push(location.hash);
               /* ... [load state using the hash value] ... */
               return true;
           }
           return false;
       }, 250
 );

(appCache - это предопределенный объект, содержащий переменные приложения). Идея состоит в том, чтобы инициировать каждое действие в приложении из значения хэша. В приличных браузерах изменение значения хэш добавляет запись в историю, в IE (< = 7) это не так. Во всех браузерах перемещение назад или вперед на страницу с другим значением хэша не вызывает обновление страницы. То, что перехватывает функция. С помощью функции каждый раз, когда изменяется значение хеш-функции (программно, или щелкнув назад или вперед), приложение может предпринять соответствующие действия. Приложение может отслеживать его собственную историю, и я должен иметь возможность отображать кнопки истории в приложении (особенно для пользователей IE).

Насколько я могу судить, это работает в кросс-браузере, и нет никаких затрат с точки зрения памяти или ресурсов процессора. Поэтому мой вопрос: будет ли это жизнеспособным решением для управления историей в XHR-приложениях? Каковы плюсы и минусы?

Обновление: поскольку я использую свою структуру homebrew, я не хотел использовать одну из существующих фреймворков. Чтобы иметь возможность использовать location.hash в IE и иметь в нем также историю, я создал простой script (да, ему нужен iframe), который может вам пригодиться. Я опубликовал его на моем сайте, не стесняйтесь использовать/модифицировать/критиковать его.

Ответ 1

Я думаю, что у вас будет сложное время, зная, пошел ли пользователь вперед или назад. Скажите, что url запускает /myapp # page1, чтобы вы начали отслеживать состояния. Затем пользователь делает что-то, чтобы сделать url/myapp # page2 Затем пользователь делает что-то, чтобы снова сделать url/myapp # page1. Теперь их история неоднозначна, и вы не будете знать, что удалить или нет.

В фреймворках истории используются iframe, чтобы обойти несогласованные вами браузеры. Вам нужно использовать iframe в тех браузерах, которые им нужны.

Еще одна проблема заключается в том, что пользователи всегда будут заходить за кнопкой браузера, прежде чем они отправятся на вашу пользовательскую кнопку возврата. У меня есть ощущение задержки при чтении истории каждые 250 мс. Может быть, вы можете сделать интервал еще более напряженным, но тогда я не знаю, что это заставит все работать плохо.

Я использовал диспетчер истории yui, и хотя он не работает идеально все время во всех браузерах (особенно ie6), он использовался многими пользователями и разработчиками. Шаблон, который они используют, довольно гибкий.

Ответ 2

Есть 3 проблемы, которые, как правило, объединяются большинством решений:

кнопка назад
bookmarkability
кнопка обновления

Решения на основе window.location.hash могут решить все три в большинстве случаев: значение в hash отображает состояние приложения/веб-страницы, поэтому пользователь может нажать один из "назад" / "вперед" /обновить "и перейти к состоянию теперь в хэше. Они также могут добавлять закладки, потому что значение в адресной строке изменилось. (Обратите внимание, что скрытый iframe необходим для IE, связанного с хешем, не влияющим на историю браузера).

Я просто хотел заметить, что решение iframe можно использовать без мониторинга window.location.hash для очень эффективного решения.

Карты Google - отличный пример. Состояние, захваченное для каждого действия пользователя, слишком велико, чтобы быть помещенным в window.location.hash(центроид карты, результаты поиска, отображение спутника по карте, информационные окна и т.д.). Таким образом, они сохраняют состояние в форме, встроенной в скрытый iframe. Кстати, это решает проблему [soft] "refresh". Они решают возможность закладки отдельно через кнопку "Ссылка на эту страницу".

Я просто подумал, что стоит знать/разделять проблемные области, о которых вы думаете.

Ответ 3

Все это важно для поддержки всего спектра браузеров, но, надеюсь, потребность в нем исчезнет. IE8 и FF3.6 представили поддержку onhashchange. Я полагаю, что другие последуют этому примеру. Было бы неплохо проверить наличие этой функции перед использованием тайм-аутов или iframes, так как это действительно самое приятное решение в настоящее время - и оно даже работает в IE!