DEV Community

Mikey Stengel
Mikey Stengel

Posted on • Updated on

Introducing state machine advent: 24 bite-sized blog posts about state machines and statecharts

TL;DR: I'm creating one piece of content each day until Christmas to explain the theory and application of state machines and statecharts.

My backstory of how and why I got to use XState

A couple of months ago, I went down the rabbit hole of looking for the best state management library. When I glanced at the number of issues in my backlog and knowing the complexity of some of the tasks, I knew that the library would need to scale extremely well and provide a great developer experience.

I stumbled upon state machines/statecharts and was immediately reminded of my limited - but horrific - experience with them in college. My professor probably gave the worst introduction to the world of finite automata I could've hoped for, but despite knowing about his incompetence, there was no way that I would ever want to think about Greek letters when writing code.

When turning to Redux, I turned a blind eye on the concept of a global store and the need for additional packages like Redux thunks to properly handle asynchronicity. Nonetheless, there was one particular event that made me pause and rethink my decision. After days of going through countless blog posts, tutorials and resources on how to write beautiful Redux apps, my attempt of creating the hello world app of state management libraries was halted when my todo mvc app looked like this:

At some point, my example app got into an invalid state where it somehow finished loading the todos while also indicating that todos are still being loaded at the same time (wut?). I simply forgot to set the loading boolean flag back to false once the todos were resolved but this should not have happened. I knew that the two states can never be present at the same time and yet my program was completely clueless about this exclusive relationship between the states. I quickly came to realize that Redux was not the "best state management library" I was hoping to find because I couldn't model the transition from one state to another with ease. This would undoubtedly introduce more bugs in the future so I had to go back to the drawing board.

Having learned from my experience with Redux, I needed a programming paradigm that would allow me to strictly model all the possible states (and their transitions) of my application. Naturally, I went back to finite state machines and found some great JavaScript implementations. After devouring their documentation and videos, I fell in love with XState.
I started using it and contrary to my instinctive belief, state machines and statecharts can be defined in plain JavaScript objects without any Greek letters. 😄 To this day, I'm still learning new things about its extensive API and have never looked back at any other state management library.

This is my very first blog post. Any feedback is greatly appreciated. 😊

About this series

I'll publish one piece of content each day to teach you about the ins and outs of state machines and statecharts. As you'll learn in this series, they'll make your app more resilient, eliminate bugs and allow you to reason about your code more easily.

Day 1:

Day 2:

Day 3:

Day 4:

Day 5:

Day 6:

Day 7:

Day 8:

Day 9:

Day 10:

Day 11:

Day 12:

Day 13:

Day 14:

Day 15:

Day 16:

Day 17:

Day 18:

Day 19:

Day 20:

Day 21:

Day 22:

Day 23:

Day 24:

Top comments (0)