Single page web apps are great, both for the end user as well as the developer.  Creating a unified, seamless experience is becoming the new standard for websites in a mobile world.  We don’t want to be using the web, we just want to be using the tools that make our lives easier.  For developers though, it can be easy to take fundamental building blocks for granted.  For instance: the back button.

A single page web app always uses the same URL and never leaves it.  This eliminates one of the key interruptions in the UX for a web app – waiting for the next page to load.  Instead of throwing your entire page out the window and starting over again, you can preserve all of the elements of the page that won’t change and then swap in the new content where it’s needed.  This works great, but if you never change the URL then the browser never knows to record that you’ve changed pages.  If you’ve been clicking through 20 links on this web app, all it takes is one click of the back button to undo all of them.  And worse yet, you’ve got no way to get back without performing all 20 clicks again.

HTML5 is positioned to address this issue once and for all, but not every browser is ready to adopt it yet.  So now we have many frameworks that fill the gap; AngularJS being chief among them.  What AngularJS does is take advantage of the fragment identifier of the URL.  Historically, the fragment identifier was used to provide links within documents without having to reload them, and all web browsers understand to record these clicks to the browser’s history.  AngularJS uses this portion of the URL to specify paths to content that should be loaded on the page without having to reload it, and at the same time log the click to the history.

As already mentioned, we live in a mobile world, and that’s pushed developers to deal with situations where even the above solution doesn’t quite work.  Let’s say I had a contacts web app.  It would list everyone by name and would load more contacts as I scrolled.  I could click through to view a contact’s details, but if I were to click the back button, I’d be back at the top of the list of contacts.  The browser wouldn’t know where I left off and how many contacts to load to get back there.  This is the sort of thing that mobile apps have little trouble with but even with AngularJS there are a few extra steps you need to perform for web apps before you can emulate this behavior.

You can find, buried away in the AngularJS documentation, a property called reloadOnSearch, which is applied to your route provider.  Switching this to be false will allow you to tell AngularJS NOT to discard the list of contacts, but still alert you and the browser to the fact that the URL has changed.  Now, when I’m finished reading my contact’s details, I can click the back button, and instead of reloading the route, my app receives a notice that the URL was updated and I should show the contacts again.  At this point, the list of contacts slides back into view exactly the way I had left it!

To see this concept in action, visit Fireworks.com with your mobile browser and look through the products and locations list.