Managing State and Front-end Development

But first, before we dive in and write code, let’s talk about web applications, Rails, and JavaScript for a second.

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

The structure of web applications

One of the main questions we’ll be dealing with is how to structure your web application so as to best manage your state. The goal is to avoid having multiple sources of truth, both by avoiding duplicating data and writing the same logic on both the client and the server side. We also want to make the program as easy as possible to understand and change.

A consistent problem in web development is that as far as the browser and HTTP server are concerned, the interaction for each page view is “stateless,” meaning each interaction is completely self-contained and has no relation to or memory of previous interactions.

This lack of state is quite useful if you are a web server, because it makes your life much easier not to have to keep track of all that state.

If you are a user of the web, however, the lack of state is annoying, because the web server never remembers anything about you. Web applications depend on maintaining your state to remember who you are and what you are doing, and so developers have created different solutions to manage the state of a user’s interaction with a web server.

Almost since the beginning of the web, a technical solution to this problem has been cookies. The cookie is a token—which is to say, 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 recreate the user’s state for each request.

Over time, interaction patterns were built up where nearly all states would be managed on the server, and the browser’s job was largely 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

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

One of the great insights of Rails is that once you’ve settled on those as the basic actions, you can remove a lot of repetitive boilerplate and assume common behavior regardless of the data’s shape. In Rails, this default behavior is somewhat encapsulated in the scaffolding that Rails creates for new resources.

If you are dealing with basic actions, it turns out web browsers can offer you a lot of help. Browsers can provide data input elements, manage the state of those form elements, and maintain a list of historical actions. Working hand in hand with a browser makes the Rails’ core set of actions more powerful.

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

Take, for example, Twitter. Twitter, which was originally built partially using Rails, can be modeled as a system where a tweet is a resource, and the user has actions to create one, show one or more, and delete one. (But not edit, which is an argument I’m not getting into here.) Is that the best way to model Twitter’s user interaction? I don’t know. Probably not. But it’s at least a pretty good way to model Twitter, and doing so gives you a big head start because you can take advantage of the power of Rails and the browsers.

Although this server-side model has many advantages, it is somewhat limited in terms of user interaction, and it’s not surprising that users began to expect that web applications would have rich and complex interactions just like desktop interactions