State machine advent: Baby's first state machine with XState (3/24)
Tags: javascript, typescript, react
Published: 2019-12-03 18:24:52

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).

```javascript
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](https://dev.to/codingdive/state-machine-advent-anatomy-of-a-state-machine-2-24-4gfo) 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.