Wednesday, April 26, 2017

Forms as state containers (in stateless web apps)

When wiring up a web application there's a lot of state involved. Only recently I learned about state management libraries in javascript, but I won't be talking about them. I think I don't need to introduce them, because I'm convinced you don't need them. Let's take a step back to see what state actually means in web apps.

Traditionally, the web is stateless, and that's a good thing. When you request a page, the server may store information about your request, for instance for analytical purposes, but it doesn't need to do so. As the HTML document is received, nothing special is stored about that document, except maybe some temporary information (like cookies) is written to disk, if you'll allow it. Every time you request the same page, it's rendered the same way and, ignoring the subject of caching, no state is retained.

The HTTP protocol is stateless by design. Therefore, traditional HTML forms are stateless too. Whenever user data is submitted to a server, the client doesn't "know" about it. The browser doesn't receive any response from the server upon submission. Another (stateless) page is simply returned, informing that the request either succeeded or failed, in which case the user should just try again. As soon as the user navigates away from a page, this information he wished to submit is lost forever. This is a known feature of the web, and users accept it for a fact. As soon as we, the developers, try to "help" a user by retaining their work, that's the moment when things get hairy...

Among other things, retaining client-side information is one of the reasons that single-page (javascript) applications emerged. Instead of navigating by way of HTTP, the user stays on the same location the entire visit, while navigation is taken over by the javascript application. In modern single-page apps (SPA's), this is not even visible. Due to push-state technology, the URL and browser history change just like with HTTP, making the integration seamless. The downside is that the developer now has to deal with the application state.

Since the advent of SPA's a lot of things changed. Using widgets, in-page requests (Ajax) and rendering based on comparing HTML snapshots (DOM diff), only parts of the page are updated, while the rest just remains as-is, making interaction seemingly much faster and snappy. These techniques again bring much more state to the SPA, making things downright impossible to manage. Even the most advanced tools keep track of the entire application in single or multiple data-structures that live alongside the UI. Changes happen in the data, rendering the app is merely a side-effect to inform a user what's going on.

In a series of posts I would like to explore an alternative to state-full SPA's, in the form of, well, forms, as the title suggested.

Next up: Forms as state containers Part 1: forms as a single source of truth

No comments:

Post a Comment