balupton/history.js — Issue #122: Update docs and demo to clarify differing purpose of state and url
Author: dobesv
Created: 2011-11-08 10:58:45+00:00
State: open

In the history system the "state" field is holds state that is independent from the URL and which is not preserved if you copy/paste the URL into a new browser.

The "url" field holds state that is the URL and which is preserved when you copy/paste the URL to a new browser.

These two methods of storing state are in fact independent, and contain different state with a different intent.

When I first started to use the history library I had believed that the two were linked together and that query parameters in the URL were in some way connected to the "state" stored in the history.

But this is in fact not the way the HTML5 history system was designed, it seems. The state object and URL can contain different and even conflicting information. The initial state of any page is empty, whereas the URL is not.

Thus, applications that include state in the URL should store and retrieve it using the url part of the history, not the state object. The state object could be used as a kind of cache in some cases, I suppose, but I'm not sure this is a worthwhile optimization.

So, my request is that the history.js readme and demo be changed so that the 'state' doesn't duplicate the fields passed in the URL query. This should hopefully reduce the confusion of future learners so they don't have to go through the same confusion as I did!

See the discussion here for more:

https://github.com/balupton/history.js/issues/99#issuecomment-2665849