Automata-based programming — JS: React

The topic of finite automata is central to frontend 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, and in most cases doesn't require you to use special libraries. Take, for example, a button that's responsible for displaying a piece of text. Its states can be described 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 highly discouraged in the backend when the state is stored in the database. Changing an automaton is incredibly difficult (changing the column type from boolean to string), so even when you're using binary logic, it's better to make a full-fledged automaton with named states. In other words, don't use a boolean field (with true/false) to store the state, use a text field that will contain the full name of the state. For example, if an article can be in two states ('published' or 'unpublished'), you shouldn't have a 'published: bool' field with the values true and false, but rather 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 frontend) 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 frontend 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 published, or it may not be. The UI is generated based on what state it's in. And this is where the most interesting part begins. Specifically, the article's published state isn't part of the UI, but the UI uses this state, and it's synchronized in the frontend and backend when changes are made. But in the UI, there are often states that are solely responsible for the appearance, but are not part of the data.

Assuming that the data coming from the backend inside our state object is stored as a list under the items key, then this raises a question: where do we write the data responsible for the UI state? I.e., where do we write the states that appear only when interacting with the user and aren't used server side?

Example: an article comes from the backend with the following structure: { id: 3, name: 'How to program', state: 'published' }. It goes to items. And you can edit it in the UI object, we use (state) isEditing, which exists only on the screen, to this end. Question: Where do I store this variable?

The easiest option is to change the article itself inside items so that it looks 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 to constantly merge so as not to lose the state of the UI. Practice has shown that it's much easier to add a separate list solely for the task of storing the state of the UI. I.e., a list called itemUIStates will appear in the state, and the element { articleId: 3, isEditing: true }.

Are there any more questions? Ask them in the Discussion section.

The Hexlet support team or other students will answer you.