Automata-based programming — JS: React

The topic of finite automata is central to any front-end development. Interactive elements are always involved in state-changing processes. Modal windows can have properties like open, hidden, button pressed, clicked, or blocked (e.g., during an AJAX request).

The examples are endless. Often these automata depend on each other, which generates a hierarchy of automata. For example, the ability to interact with an item on the screen may appear only after pressing the edit button.

In React, working with automata is incredibly simple. In most cases, it doesn't require you to use special libraries. Take, for example, a button responsible for displaying a piece of text. We can describe its states as follows:

• By default, the text is hidden (hidden state)
• Clicking the button displays the text (shown state)
• Clicking again hides the text (hidden)

In this case, the button has two states, so you can simplify the task and use a flag as a status indicator. Let's call it isShown.

Using flags with boolean values is discouraged in the backend when we store the state in the database. Changing an automaton is incredibly difficult because of changing the column type from boolean to string. So even when you use binary logic, it's better to make a full-fledged automaton with named states. In other words, don't use a boolean field to store the state. It is better to use a text field with the full name of the state.

For example, an article can be in two states — published or unpublished. You shouldn't have a published: bool field with the values true and false. It is better to use a publishing_state field with the values published and unpublished.

See the Pen js_react_fsm by Hexlet (@hexlet) on CodePen.

Most of the code in React (as well as the entire front end) looks exactly like the example above. Events generate state changes in the data, which, in turn, changes the view. The number of finite automata in front-end applications is growing at an astronomical rate. The most important thing is to see them and distinguish them explicitly.

State structure

The data React works with usually comes from the backend. This data is also involved in different processes and different states.

For example, an article may be either published or not. The UI is generated based on what state it's in. And this is where the most curious part begins. Specifically, the article's published state isn't part of the UI, but the UI uses this state. It synchronizes in the front end and back end when we make changes. But in the UI, states can be solely responsible for the appearance but are not part of the data.

Let us assume that we store the data from the backend inside our state object as a list under the items key. Then this raises questions: where do we write the data responsible for the UI state? Where do we write the states that appear only when interacting with the user and aren't used server side?

For example, an article comes from the backend with the following structure: { id: 3, name: 'How to program', state: 'published' }. Then it goes to items.

Now we can edit it in the UI object, using the state isEditing. It exists only on the screen to this end. So, where do we store this variable?

The easiest option is to change the article inside items. It should look like this: { id: 3, name: 'How to program', state: 'published', isEditing: true }.

Although at first glance this seems reasonable, it brings more problems than benefits. Most of these problems are related to synchronization. Sometimes, you need to send the entire article to the server after changes, and sometimes you need to reread it from the backend.

In such a situation, you'll either need to extract only the necessary data or constantly merge it not to lose the state of the UI. The practice has shown that it is easier to add a separate list solely for storing the state of the UI. For example, a list called itemUIStates will appear in the state with the element { articleId: 3, isEditing: true }.