The problems of working with History API, and how we solved them
Have you ever worked with the History API to build your apps? No? Well you should try it – it’s awesome!
You don’t believe me? You think it sucks? Well, that’s probably because you’ve encountered some of the many problems with it:
- In some cases, a popstate event is triggered at pageload for no apparent reason. This happens when you refresh a page that previously had a state set. Most of the time you don’t need this, as you can check the window.history.state from JS on page load if you need to do anything with it.It feels more natural that a popstate event is only triggered when the user hits the back/forward buttons, right?
- Why include the title parameter in the pushState and replaceState methods, if the browsers are not implementing it at all? It’s not rocket science to change the document.title parameter.Come on, Mozilla and Google! Microsoft, we know you try so hard – just kill IE already!
- Google Analytics doesn’t play well with the History API yet, but in this case it’s understandable. Not every pushState or popState event is meant to trigger an Analytics response.
After struggling with these issues for a while, I put together a small JS library that provides almost the same interface as the native history object, but fills the gaps mentioned above.
It’s included in our open source framework, Ignite WP. Check out the source here and documentation here.
