0

A good single-page web application should in my opinion be as close as possible (and sensible) to a traditional web application, which does a full page (re-)load on every user action. In particular, a single-page web application should support the browser history, including the back and forward buttons.

Most frameworks for single-page web applications do support the browser history. But they do not seem to emulate one crucial thing: When I am on, say, page 1 of a traditional web application and fill in a form field, navigate away to page 2 of the application and then click the back button, the browser will restore my input.

With a single-page web application, one of two things usually happens: Either the form field of page 1 is still part of the DOM (but hidden) on page 2 (or at least part of a Javascript data structure), so that the application may show me the filled-in form field again after navigating back, or the form field is created anew everytime I visit page 1 (either through direct navigation or by pressing the back button). In the latter case, my former input is not restored.

It seems clear that the former is the better. But even this solution isn't perfect: In a tradition web application, each history entry has its own cached values of form fields, even if the history contains the previously mentioned page 1 several times. The single-page application which doesn't recreate the form fields on every in-application navigation, however, caches only a single value for every form field.

One idea to solve this problem and making single-page web applications better, would be to store the values of the form fields in the data attribute of the pushState and replaceState methods of the HTML5 history interface to have them stored along the other history information. Of course, the current history entry has to be kept updated before the user navigates away, so one would have to use onchange-event handlers on all form controls that update the current history entry using replaceState.

Now my question is whether there is a better solution to the problem described above and whether there are any single-page web application frameworks/libraries that take care of it.

Marc
  • 4,327
  • 4
  • 30
  • 46
  • 1
    I think you've got a good handle on it, though it can get even more complicated. If you navigate forward to some form and complete it, then the server-side state has changed. After that, going "back" may need to get to the same *places* but with new contextual information (or else subsequent POST operations may not make any sense). – Pointy Oct 27 '12 at 22:08
  • Oh and also there are some interesting security-related issues with keeping form data in the history (or in local storage or whatever) if your application happens to involve financial or medical information, esp. when dealing with mobile devices. – Pointy Oct 27 '12 at 22:09
  • @Pointy: These are important points, of course, but they also apply to traditional web applications, don't they? So emulating the behaviour of traditional web applications as close as possible may also mean emulating bad things as well. But still, it would be close to the user's expectation. – Marc Oct 27 '12 at 22:21
  • yes you're right about that! I think that's probably what got web application designers all freaked out about the "Back" button a decade ago. So in some ways, it's actually a lot *easier* in a single-page app because you have more control. Not "easy" in absolute terms however :-) – Pointy Oct 27 '12 at 22:25

0 Answers0