Czy monitorowanie location.hash rozwiązanie dla historii w aplikacjach XHR?

Question

Jak powszechnie wiadomo, w aplikacjach internetowych XHR (alias AJAX) nie jest tworzona historia Twojej aplikacji, a kliknięcie przycisku odświeżania często usuwa użytkownika z jego bieżącej aktywności. Natknąłem się na location.hash (np. http://anywhere/index.html#somehashvalue), aby obejść problem odświeżania (użyj location.hash, aby poinformować twoją aplikację o jego bieżącym stanie i użyj procedury obsługi ładowania strony, aby zresetować ten stan). To naprawdę miłe i proste.

Doprowadziło mnie to do myślenia o użyciu location.hash do śledzenia historii mojej aplikacji. Nie chcę użyć istniejących bibliotek, ponieważ używają iframe itp Więc oto moja niklu i bilon: Gdy aplikacja strona ładuje zacznę tak:

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 
); 

(pamięć podręczną aplikacji jest predefiniowany obiekt zawierający zmienne aplikacji) Pomysł polega na uruchomieniu każdej akcji w aplikacji z wartości mieszania. W przyzwoitych przeglądarkach zmiana wartości hash dodaje wpis do historii, w IE (< = 7) tak nie jest. We wszystkich przeglądarkach nawigacja wstecz lub do strony o innej wartości skrótu nie powoduje odświeżenia strony. Właśnie tam przejmuje funkcja interwałowa. Dzięki funkcji za każdym razem, gdy wykryta zostanie zmiana wartości skrótu (programowo lub poprzez kliknięcie wstecz lub do przodu), aplikacja może podjąć odpowiednie działanie. Aplikacja może śledzić jej historię i powinienem móc wyświetlać przyciski historii w aplikacji (szczególnie dla użytkowników IE).

O ile wiem, działa to w przeglądarce krzyżowej i nie ma żadnych kosztów związanych z zasobami pamięci lub procesora. Moje pytanie brzmi: czy byłoby to opłacalne rozwiązanie do zarządzania historią w aplikacjach XHR? Jakie są plusy i minusy?

Aktualizacja: ponieważ używam mojej architektury homebrew, nie chciałem używać jednej z istniejących frameworków. Aby móc używać location.hash w IE i mieć go również w swojej historii, stworzyłem prosty skrypt (tak, potrzebuje on elementu iframe), który może ci się przydać. Opublikowalem go pod numerem on my site, nie krępuj się używać/modyfikować/krytykować.

Answer 1

Myślę, że będziesz miał trudny czas, wiedząc, czy użytkownik przeszedł do przodu lub do tyłu. Wypowiedz adres URL zaczyna/myapp # page1, aby rozpocząć śledzenie stanów. Następnie użytkownik robi coś, aby url/myapp # page2 Następnie użytkownik robi coś, aby ponownie url/myapp # page1. Teraz ich historia jest niejednoznaczna i nie będziesz wiedział, co usunąć lub nie.

Struktury historii używają ramek iframes do obejścia niespójności w przeglądarce, o której wspomniałeś. Musisz tylko używać ramek iframe w przeglądarkach, które ich potrzebują.

Kolejną przeszkodą jest to, że użytkownicy zawsze będą używać przycisku wstecz w przeglądarce, zanim przejdą do niestandardowego przycisku wstecz. Mam wrażenie, że opóźnienie w czytaniu historii będzie zauważalne co 250ms. Być może możesz zrobić interwał jeszcze mocniej, ale wtedy nie wiem, czy to sprawi, że rzeczy źle się sprawdzą.

Użyłem menadżera historii yui i chociaż nie działa idealnie cały czas we wszystkich przeglądarkach (szczególnie ie6), to jest używane przez wielu użytkowników i programistów. Wzór, którego używają, również jest dość elastyczny.

Answer 2

Istnieją 3 problemy, które stają się munged razem przez większość rozwiązań:

1. przycisk wstecz
2. bookmarkability
3. przycisk odświeżania

window.location.hash rozwiązania opartego na może rozwiązać wszystkie trzy dla większość przypadków: wartość w mapach hash do stanu aplikacji/strony internetowej, więc użytkownik może nacisnąć jeden z "wstecz"/"do przodu"/"odświeżyć" i "jum" p do stanu teraz w haszyszu. Mogą również tworzyć zakładki, ponieważ zmieniła się wartość na pasku adresu. (Zauważ, że ukryty iframe jest potrzebny do IE związany z hashem nie wpływającym na historię przeglądarki).

Chciałem tylko zauważyć, że rozwiązanie tylko iframe może być używane bez monitorowania window.location.hash dla bardzo skutecznego rozwiązania.

Mapy Google są świetnym tego przykładem. Stan przechwytywany dla każdego działania użytkownika jest zbyt duży, aby można go było umieścić w window.location.hash (centrum map, wyniki wyszukiwania, widok satelity względem mapy, okna informacyjne itp.). Zapisują więc stan w formie osadzonej w ukrytym iframe. Nawiasem mówiąc, rozwiązuje to również problem "miękkiego" "odświeżania". Rozwiązują one osobność książkową oddzielnie za pomocą przycisku "Link do tej strony".

Po prostu pomyślałem, że warto znać/oddzielić problematyczne domeny, o których myślisz.

Answer 3

Wszystko to jest ważne dla obsługi pełnego zakresu przeglądarek, ale miejmy nadzieję, że zniknie. IE8 i FF3.6 wprowadziły obsługę dla onhashchange. Wyobrażam sobie, że inni pójdą w jego ślady. Dobrym pomysłem byłoby sprawdzenie dostępności tej funkcjonalności przed użyciem limitów czasu lub elementów iframe, ponieważ jest to obecnie najmilsze rozwiązanie - i działa nawet w IE!