XState is a JavaScript/TypeScript library to create state machines and statecharts. It allows us to model state machines and all of their characteristics using a JSON object.

Our first state machine will be a binary light switch, meaning it has only two states (active/inactive).

import { Machine } from 'xstate';

const lightSwitchMachine = Machine({
  id: 'lightSwitch',
  initial: 'inactive',
  states: {
    active: {
      on: {
        TOGGLE: 'inactive'
      }
    },
    inactive: {
      on: {
        TOGGLE: 'active'
      }
    },
  }
});

XState syntax

Before we dissect what our code above does, I want to spend some time on the basics of XState.

XState provides a factory function called Machine. We'll use this function to create an abstract state machine. Later into the series, we'll explore how we can invoke and use the machine in our web applications but for today, we'll try to get a solid understanding on the fundamentals first.

Looking at the example, there are a couple of reserved xstate keywords that you should know about.

on holds all the events and their state transitions. Event names are specified as key of the on object (e.g TOGGLE) whereas the value of the event specifies the target state. Once the event is send to the machine, it transitions to the new state; this is what we refer to as a state transition.
initial to specify the initial state of the machine.
states an object of all the possible states.
id to uniquely identify a machine. Don't worry about this part as it'll only become relevant much later into the series. I usually use the machine name as an id.

How does our state machine work and what does it do?

Having learned about the XState syntax, let's determine what our machine does in plain english.

• Our machine has two possible states: inactive and active.

• It starts out in the initial or default state of inactive.

• Given the machine is in the inactive state, and receives a TOGGLE event, it transitions to the active state.

• Given the machine is in the active state, and receives a TOGGLE event, it transitions to the inactive state.

Notice how we need both the current state and the event to reliably determine the next state. I can't stress the importance of state + event => newState enough and the fact that it is not enforced by most state management libraries is the sole cause for a lot of bugs.

Updated state machine glossary (with examples)

Repetition is the key to mastery so I updated the glossary of yesterday with the example from above.

states describes the set of possible states that your application can be in. (e.g inactive | active)

state represents how your application should behave at any given point (e.g inactive)

events external input that is mostly send to state machines within event handlers (e.g TOGGLE event could be send once a user clicks the actual light switch)

transitions occur as a reaction to events and transition your current state to another state. state+event => newState (e.g inactive (state) + TOGGLE (event) = active (state))

About this series

Throughout the first 24 days of December, I'll publish a small blog post each day teaching you about the ins and outs of state machines and statecharts.

The first couple of days will be spend on the fundamentals before we'll progress to more advanced concepts.