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

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

19 голосов
/ 20 февраля 2009

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

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

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). </p>

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

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

Ответы [ 3 ]

8 голосов
/ 01 марта 2009

Существует три проблемы, которые обычно объединяются большинством решений:

  1. кнопка возврата
  2. bookmarkability
  3. кнопка обновления

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

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

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

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

5 голосов
/ 20 февраля 2009

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

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

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

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

2 голосов
/ 29 марта 2010

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

...