UI State Management

From Object-Oriented to Functional

Nowadays state management has become a common challenge when developing web applications. The time when we directly changed the UI for display data is long gone. All major UI libraries come with a new approach, changing the UI means actually changing the state.

The obvious question now is what state actually is.

State is data basically.
Is any data used in the application state?
The answer is “No”. Only the data that is stored becomes state. If the data doesn’t change then is just a configuration object used inside the application. If the data is taken from the API and then displayed on the screen without being stored we are dealing with data transfer objects.

Modifying the state in order to update UI, instead of changing directly the screen, simplifies the task of rendering the UI.

Consider for example the operation of displaying a list of notes. Presenting the list means changing the UI. In order to show the list on the screen we update the state with the new list, then the UI framework recognizes the change and updates the UI.

Detecting the state changes is done in two different ways by the current UI libraries. Some of them like Svelteand Vue uses “reactive properties”. These properties are connected to pieces of UI. When the reactive property changes the HTML template using it is re-rendered. Other libraries like React use immutable objects and detect changes by comparing the object references. When the object reference changes, the piece of UI using that object re-renders.

Is this technique of changing state instead of modifying the UI actually worth doing? It seems it does. All major libraries took this approach. Instead of thinking in terms of changing the UI elements, we think about updating pieces of data.

For example:

• rendering a list of notes → means changing the list of notes in the state object
• rendering a list of categories → means the same thing, updating the list of categories in the state object
• selecting a category → implies changing the selected category in the state
• opening a dialog → implies updating a boolean marking if the dialog should be shown or not

This technique simplifies the thinking process. It should be easier to think about changing state than updating UI elements.

Wait a minute, is it really so easy?

It seems is not. What this technique actually does is to move the task of changing the UI to changing data. Maybe updating data is easier to think about but the complexity is still there.

Different libraries attempt to handle the complexity in these data changes using distinct solutions all of them trying to make things easier to do.

In this book, we are going to look at four solutions for state management. We start from options taking an object-oriented approach, then move to solutions taking a functional approach, and in the end arrive at a solution using only pure functions.

Requirements

In order to see state management in practice, we are going to create a note-taking application that allows us to add, edit, delete notes, and organize them into categories.

The board displays all notes for the selected category.

Pressing the add button on the board opens a dialog for creating a new note.

The same dialog is used for editing an existing note. From here the user can also delete the note.

The left menu allows the user to add a new category or to delete the existing ones. The category should be selected before being deleted.

Now that we know the requirements and have started the fake API we can begin building the application.

Enjoy the learning journey!

Click here to get a sample of the book.