Managing state at different levels of complexity is hard. Different tools make different trade-offs between readability, complexity and speed of development. The worst part is that as apps get more complex, it’s easy to regret choices that were made early on.

This series of articles should help you make the right choice off the bat. The plan is to cover a bunch of state use cases, starting with the simple and graduating to more complexity as we go. We’ll see how easy they are to write, and also how they survive changing requirements.

Today, we’re starting with modals.

Many React applications follow the Flux architecture popularised by Redux. This setup can be characterised by a few key ideas:

1. It uses a single object at the top of your app which stores all application state, often called the store.
2. It provides a single dispatch function which can be used to send messages up to the store. Redux calls these actions, but I'll be calling them events - as they're known in XState.
3. How the store responds to these messages from the app are expressed in pure functions - most often in reducers.

This article won't go into depth on whether the Flux architecture is a good idea. David Khourshid's article Redux is half a pattern goes into great detail here. For the purposes of this article, we're going to assume that you like having a global store, and you want to replicate it in XState.

XState offers several primitives for representing long-running application processes. These are usually expressed as services. I’ve written a bit about services here - but today I wanted to talk about my favourite way of expressing services: the Invoked Callback.

XState offers several ways of orchestrating side effects. Since it’s a statechart tool, with significantly more power than a reducer, side effects are treated as a first-class concept.

State machines offer several API’s for expressing state. Like other tools, you can keep arbitrary values in a store (usually expressed as an object) called context.

XState offers two options for declaring machine definitions:

import { Machine } from 'xstate';

const machine = Machine({ ...config });

…or…

import { createMachine } from 'xstate';

const machine = createMachine({ ...config });

This can be confusing for beginners. Why are there two very similar-looking methods? What’s the difference?

The finite state machine is one of the oldest models of computation in computer science. It’s older than the web, older than any programming language you can think of, and probably older than you. Just ask Mealy (1955) or Moore (1956). Finite state machines (FSMs) can be implemented in any modern language using control-flow statements, yet there’s most likely a state machine library (if not many) in all of those languages.

XState can feel overwhelming. Once you’ve gone through Kyle or David’s courses and read through the docs, you’ll get a thorough understanding of the API. You’ll see that XState is the most powerful tool available for managing complex state.

The challenge comes when integrating XState with React. Where should state machines live in my React tree? How should I manage parent and child machines?

My code contains Horcruxes. I’m not proud to admit it, since to make a Horcrux you need to commit a murder. The murders seemed intuitive at the time, and were usually for expedience. But nonetheless, I am a murderer.

Let’s talk about how I got here.

TL;DR: Bad booleans represent state. Good booleans are derived from state.