State Machines and Frontend Development
State machines should be one more instrument or our software engineer toolkit.
Private Todo App
We are working on a new fantastic todo app. We want to show the list of todos only to logged-in users. Users that are not logged in should see a button to log in.
Therefore, we add use a boolean to know what to render:
if (loggedIn) {
<Todos />
} else {
<LoginButton />
}
New Requirements
For security reasons, we want to log out after four minutes of inactivity. Yet, the UX designer insists that we show a warning one minute before logging out to inform the user.
The behavior has evolved from a single boolean to more complex behavior. Most probably, we’ll hardcode the behavior in some parent component and call it a day. It will work.
Yet, I’d like to show a tool that greatly helps in this scenario: State Machines.
State Machine
A State Machine is a model describing a system that can be in one state at a time. The model defines how the system changes based on inputs (or events).
For example, the On/Off switch of the kitchen light is a state machine:
It has two states: “On” and “Off,” and one event: “push.” It’s either on or off, but not in both simultaneously. And the switch changes state based on the event of pushing the switch.
Let’s look at a slightly more interesting example: a turnstile or turn gate.
Turnstiles are state machines with two states: “Open” and “Close,” and two events: “pass card” (or insert coin or ticket) and “push.” If we pass the card, it moves to the “Open” state. If we “Push,” it moves to the “Closed” state.
There are many state machines in our everyday life: elevators, traffic lights, vending machines, etc.
Back to Todo App
Back to our todo app, let’s model the desired behavior of inactivity, warning notifications and logging out with a state machine:
State Machine Mindset
The concept of state machines is powerful for software developers. There are always behaviors that start as a single boolean (logged in or logged out) and become entangled with additional requirements.
Testing and maintaining that complexity becomes a hassle unless we model the behavior explicitly. State machines are the perfect model for it.
State machines are a big mathematical field, but we don’t need to be experts to profit from them. Instead, a basic understanding of them is enough to help us in our daily tasks.
State machines should be one more instrument or our software engineer toolkit.
For more details, I strongly recommend watching this video from the XState creator and reading about Statecharts. Statecharts are beefed-up state machines handy for software development.
If you like this post, consider sharing it with your friends on twitter or forwarding this email to them 🙈
Don't hesitate to reach out to me if you have any questions or see an error. I highly appreciate it.
And thanks to Sebastià for reviewing this article 🙏