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

Comments

Post a Comment

Popular posts from this blog

Abandoning hope... and XForms

Sometimes a decision must be made. I have invested many hours in a standard that is quite complex and tedious to maintain, and that was great fun, but enough is enough. Why did I invest in XForms when it took so much effort and time? Because I believe standards are good and good standards come from the W3C and the XML community. Also, I always had somewhat of an inferiority complex in IT development that I tried to compensate by using techniques supposedly invented for common folk, i.e. non-programmers. Both are bad reasons from where I now stand. I took up XForms because I was infected by the enthusiasm of a friend (who was even quicker to abandon it) about 3 years ago. At first I assumed it just used a model from which to infer a form. It turned out it was like a superset of HTML forms with options for displaying and validating data. This was largely taken up by HTML5, as we all know. The Model remains the core of XForms, but the W3C is slow to respond to innovations and the need f
Read more

JS Journey into outer space - Day 5

This article was written as part of a knowledge sharing program I created for front-end developers. It builds up to creating reusable abstractions by studying async transducers. Day 5 It's time to add more operators. We already have map , but what if the mapping function returns another "container" value, like an array or observable? 🦉 In RxJS some operators like switchMap , concatMap , or mergeMap will expect a "project" function that returns an observable (or promise or array), but what happens then? First map is applied with the project function and after that the result is "flattened". In other words: when the returned (inner) observables emit, the mapped (outer) observable emits those values instead. Since RxJs streams have a specific async behaviour the flattening process takes concurrency into account: mergeMap will flatten inner observables whenever they complete, regardless of the order, but concatMap will preserve the order of the ou
Read more

JS Journey into outer space - Day 4

This article was written as part of a knowledge sharing program I created for front-end developers. It builds up to creating reusable abstractions by studying async transducers. Day 4 Now we have modified transduce to handle async it's time to figure out how it can handle observables. Kickoff 🏈 First we need to pass the onNext function which kicks off the callback chain. In RxJs this is called subscribe instead, so let's rename the parameter and the callbacks to be more in line with RxJs : function transduce ( input , fn , subscribe , onError , onComplete , init ) { subscribe ( input , { next : ( cur ) => { init = fn ( init , cur ) ; } , error : ( err ) => { onError ( init , err ) ; } , complete : ( ) => { onComplete ( init ) ; } } ) ; return init ; } ; 🦉 Observables are considered a push-style of dealing with many values, while generators are pull-based. In
Read more