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

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

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

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-приложениях? Каковы плюсы и минусы?

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


javascript xmlhttprequest ajax browser-history
person KooiInc    schedule 20.02.2009    source источник

Ответы (3)


arrow_upward
5
arrow_downward

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

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

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

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

person JeremyWeir    schedule 20.02.2009
comment
Я думала об этом. Возможно, загромождение истории также связано с контролем приложения - чтобы убедиться, что пользователь попадает туда, куда приложение ведет его / ее, чтобы его / ее позиция всегда была ясна? - person KooiInc; 20.02.2009

arrow_upward
8
arrow_downward

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

  1. Кнопка назад
  2. возможность закладки
  3. кнопка обновления

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

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

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

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

person Crescent Fresh    schedule 01.03.2009
comment
На самом деле 4 вопроса. Вы пропустили состояние. - person T9b; 30.05.2011

arrow_upward
2
arrow_downward

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

person Russell Leggett    schedule 29.03.2010