Managing State and Front-end Development

Many decisions concerning program structure in web applications are about how to manage state, which is the data that controls the interactions between the user and the application. Managing state includes both the location of that data itself and the logic that manipulates that state.

The structure of web applications

A main question we’ll deal with is how to structure our web application to manage our state in the best way. The goal is to avoid having multiple sources of truth by preventing duplicate data and writing the same logic on both the client and the server side. We also want to make the program simple to understand and change.

Problems

A consistent problem in web development is that the browser and HTTP server consider each page view’s interaction as stateless. Stateless means that each interaction is entirely self-contained. For the web server, each request has no relation to or memory of previous requests.

This statelessness is quite useful for web servers because the server doesn’t need to keep track of any state. However, for a web user, statelessness is annoying because the web server never remembers anything about them.

Solution

Web applications depend on maintaining your state to remember who you are and what you’re doing, so developers have created different solutions to manage the state of a user’s interaction with a web server.

Since the beginning of the web, a technical solution state management has been cookies. A cookie is a small amount of data, often a random string of characters, generated by the server and managed by the browser. The cookie allows the browser to identify itself, and an application server can use that identification to remember the user’s state for each request.

Over time, interaction patterns were created where nearly all states could be managed on the server, and the browser’s job was essentially to ask for new pages or new parts of pages, receive the result of the state change, and display it to the user.

Designing around basic web actions

Advantages

Ruby on Rails is a framework for managing the state of a web application on the server. Rails is built around the idea that most web interactions involve a very small set of operations. This set of actions is often abbreviated as CRUD: Create, Read, Update, and Delete. In Rails, these actions are represented by the seven operations provided for a standard resource (create, new, show, index, edit, update, and delete).

show, index, edit, update, and delete).

One of the great insights of Rails is that once we’ve settled on this set of basic actions, we can remove repetitive boilerplate code and use standard behavior, no matter what shape the data is in. In Rails, this default behavior is often defined by the scaffolding that Rails creates for new resources.

Web browsers are very helpful in dealing with these basic actions. Browsers can provide data input elements, manage the state of form elements, and maintain a list of historical actions. Working hand-in-hand with a browser makes Rails’ core actions more powerful.

In fact, the basic set of Rails interactions is so powerful that it is worthwhile to take things that are not necessarily fundamental resource interactions and model them as if they were.

For Example

Take, for example, Twitter, which was originally built in part using Rails. Twitter can be understood as a system where a tweet is a resource, whereby the user can create one, show one or more, and delete one. Is that the best way to model Twitter’s user interaction? Probably not. But it’s illustrative for our purposes and helps us understand how we can take advantage of the power of Rails and the browsers.

The server-side model has many advantages but was limited in terms of user interaction ten years ago. This created problems when users expected web applications to have the same rich and complex interactions as desktop ones. Client-side logic was one response to this problem. Another was making the browser markup, particularly CSS, more robust to allow browsers more access to complex interactivity.