Is monitoring location.hash a solution for history in XHR apps?

Question

As is well known, in XHR (aka AJAX) web applications no history for your app is build and clicking the refresh button often moves the user out of his/her current activity. I

Answer 1

All that stuff is important for supporting the full range of browsers, but hopefully the need for it will go away. IE8 and FF3.6 both introduced support for onhashchange. I imagine that others will follow suit. It would be a good idea to check for the availability of this functionality before using timeouts or iframes, as it is really the nicest solution currently out there - and it even works in IE!

Answer 2

There are 3 issues that tend to get munged together by most solutions:

1. back button
2. bookmarkability
3. refresh button

The window.location.hash based solutions can solve all three for most cases: the value in the hash maps to a state of the application/webpage, so a user can press one of "back"/"forward"/"refresh" and jump to the state now in the hash. They can also bookmark because the value in the address bar has changed. (Note that a hidden iframe is needed for IE related to the hash not affecting the browser's history).

I just wanted to note however that an iframe only solution can be used without monitoring window.location.hash for a very effective solution too.

Google maps is a great example of this. The state captured for each user action is way too large to be placed into window.location.hash (map centroid, search results, satellite vs map view, info windows, etc). So they save state into a form embedded in a hidden iframe. Incidentally this solves the [soft] "refresh" issue too. They solve bookmarkability separately via a "Link to this page" button.

I just thought it's worthing knowing/separating the problem domains you are thinking about.

Answer 3

I think you'll have a tricky time knowing if a user went forward or back. Say the url starts /myapp#page1 so you start tracking states. Then the user does something to make the url /myapp#page2 Then the user does something to make the url /myapp#page1 again. Now their history is ambiguous and you won't know what to remove or not.

The history frameworks use iframes to get around the browser inconsistencies you mentioned. You only need to use iframes in the browsers that need them.

Another con is that users will always go for their browsers back button before they will go for your custom back button. I have a feeling the delay on reading the history every 250ms will be noticeable too. Maybe you can do the interval even tighter, but then I don't know if that'll make things perform badly.

I've used yui's history manager, and although it doesn't work perfectly all the time in all browsers (especially ie6), it's been used by a lot of users and developers. The pattern they use is pretty flexible too.