State Machines and Frontend Development
3 min read

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 🙏

Thanks for reading, don't be a stranger 👋

GIMTEC is the newsletter I wish I had earlier in my software engineering career.

Every other Wednesday, I share an article on a topic that you won't learn at work.

Join more than 5,000 subscribers below.

Thanks for subscribing! A confirmation email has been sent.

Check the SPAM folder if you don't receive it shortly.

Sorry, there was an error 🤫.

Try again and contact me at llorenc[at] if it doesn't work. Thanks!