Statecharts are a formalism for modeling stateful, reactive systems. This is useful for declaratively describing the behavior of your application, from the individual components to the overall application logic.

xstate

Learn Xstate

Jotai's state management is primitive and flexible. This gives you room to build, compose, and share state throughout your application exactly how you need it.

This flexibility can become hard to manage when you have complex requirements that span across a number of states your application can be in.

Jotai lets you leverage other state management solutions through integrations so that you can solve the problem you're facing exactly how you need to.

One of those integrations is XState. XState gives you a safe abstraction to enumerate and handle the complex states your application can be in.

With Jotai + XState, you get the flexibility and ease of use of Jotai with the power of XState.

XState is a sophisticated library to provide a better and safer abstraction for state management. 

React is one of the web’s most popular frameworks for building JavaScript applications. 

If you know what you’re doing, React can drastically simplify how you build, use, and maintain code.

Whether you’re a React newbie or you’re ready for advanced techniques, you can level-up with egghead. Explore our in-depth courses, lessons, and community resources to build more powerful applications and crack open your career.

react

Complex State Management in React with Jotai and XState

The difficulty of managing state is one of the primary reasons our applications become so complex. We try and manage this complexity with a lot of booleans, somewhat semantic variables like `isLoading`, `wasFetched`, and `hasError`, and over-engineered systems that are _still_ full of bugs. Surely, there's a better way.

That better way is *state machines*.

State machines formalize how we define and transition through the states of our application and give us ultimate control of the most complex parts of our apps.

In this course, we will explore the problems state machines purport to solve, like boolean explosion. We'll try to solve it our own way first, get so far, and then demonstrate how state machines get us all the way. After that, we'll dive into the XState library, JavaScript's premiere state machine library, to learn its API and how to use it to solve our problems.

By the time you're done taking this course, you should have a solid education about state machines and be able to start applying them.

Introduction to State Machines Using XState

Our applications have lots of states that they can be in.

We usually remember “Loading” and “Successful”. If we’re having a particularly good day, we’ll get “Error” handled as well.

But what about other states that our application can be in?

Things like “Haven’t requested yet” or “The request was successful but there isn’t any data for us to show”.

It’s frustrating to think you’re “done” and then an edge case shows up (and this cycle repeats at least one more time).

Fed up with forgetting to handle the edge cases that appear when developing UIs, Isaac Mann started looking for a solution.

The answer? State machines.

In this course, Isaac will teach you how to plan and visualize your application’s states and the transitions between them through the creation of a React & XState powered Star Wars quiz app.

Construct Sturdy UIs with XState

Finite state machines force you to do some up front thinking and be explicit about the states and transitions that are valid for your program.  We’ll use the XState visualizer tool to create a state machine to manage an http request.

Handle http request state with XState

While the order of actions in XState is fairly clear, how `assign`s are handled in them is non-obvious.

If you have a scenario where you try and utilize `context` in one action, then `assign` a new value to `context`, and _then_ try and utilize the new context in another action, you'll find that actually _both_ actions received the new `context` as their argument. Why does this happen?

This happens because `XState.Machine.transition` is a pure function. In order to remain pure, it does not run the actions, it accumulates them into an `actions` array that is returned in the next state object. Since `transition` does not run any side effects, it must calculate the next `context` object and return this on the state object as well. Thus, any action returned is then called in the interpreter with the next context, _not the context assumed to exist at the time and order the action was written_.

How Action Order Affects Assigns to Context in a XState Machine

Actions are "fire-and-forget" side effects that are triggered by transitions. We set functions on a transition object's `actions` property to have them called when a transition is taken.

```javascript
//...
EVENT_NAME: {
  target: 'name-of-state-to-transition-to',
  actions: [(context, event) => { sideEffectToFire(context, event) }]
}
//...
```

Add Actions to Transitions to Fire Side Effects

The passing of time can be represented as an event in XState. Rather than requiring the user to send an event after an amount of time has passed, XState provides the `after` property.

The value of `after` is an object whose keys are the milliseconds that should pass before a transition is taken. Consider a stop light transitioning from yellow to red after three seconds:

```javascript
//...
yellow: {
  after: { 3000: 'red' }
},
red: {
  //...
}
//...
```

We can also create dynamic delays with expressions using the `options` object as the second argument to `Machine`. This is also demonstrated in the lesson.

Delay XState Events and Transitions

Actions aren't limited to being called on transitions. They can also be called when we enter or exit a state node. This is done through the `entry` and `exit` properties.

The API for `entry` and `exit` actions is the same as that for `actions` on transitions. It can receive a single function or an array of functions, each which will be called with the next `context` and the `event` object that caused the transition.

This is a powerful way to fire side effects based on states rather than transitions.

```javascript
//...
states: {
  broken: {
    entry: [
      (context, event) => {
        sideEffectToFireWhenWeEnterTheBrokenState(context, event)
      }
    ],
    exit: [
      (context, event) => {
        sideEffectToFireWhenWeExitTheBrokenState(context, event)
      }
    ]
  }
}
```

Trigger Actions When Entering and Exiting a XState State

As our state machines grow more complex, we might find ourselves in a situation where a state should only exist if the machine is already in another state. To do this, we can use hierarchical states.

Instead of attempting to define all the states of a machine at a top level, we can nest states that should only be available as children of a parent state. These substates are written _exactly_ like the states of the top level of a machine: with an `initial` property, and the `states` of the nested state graph.

Using hierarchical states is a great way to avoid needing to check for booleans in an application. If a state can only exist when another state exists, consider if the one isn't in fact a child of the other.

Simplify State Explosion in XState through Hierarchical States

Generally speaking, state machines do not and should not have a sense of _time_. They are intended to be pure functions that receive a state and event and return the next state. Pure functions by design have no sense of _history_.

Yet, it is occasionally useful to return to a previous state. How is this accomplished? With history state nodes. Each state object returned by XState contains a special property that points to the previous state. When a history state node is defined and is the target of a transition, the machine returns to this previously stored state.

We can create a history node by defining the `type` as `history`, and setting the `history` property to either `shallow` (the default) or `deep`.

Recall Previous States with XState History States Nodes

Consider a text input. It would be impossible for anyone to model every value you could possibly put into it, because the number of possible values is infinite. This is an infinite state.

Infinite state can be tracked and utilized by XState machines as "extended state". This extended state is called `context`. Context is passed to every function that is triggered by the machine: actions, activities, guards, and more.

In this lesson we learn how to set `context` and update it through `assign` actions.

Track Infinite States with with XState Context

Unbeknownst to many, promises are state machines. They exist in either an `idle`, `pending`, `resolved` or `rejected` state. Because they can be modeled as state machines, we can invoke them when we enter a state in a `Machine`.

We invoke services such as a promise by using the `invoke` property on a state node. When the state is entered, the `src` of the `invoke` object is called. In the case of promises, the `Promise` is called. When the `Promise` resolves, the `onDone` transition is taken. When the `Promise` rejects, the `onError` transition is taken. In either case, the data returned from the promise, whether resolved or errored, is passed back on the event object as `event.data`.

Invoking a Promise for Asynchronous State Transitions in XState

We can invoke a callback as a service when we enter a state in XState. This gives us the ability to trigger various functionality by responding to events sent to the service, and allows us to send events _back_ to the parent machine.

We do this by writing a "callback handler" and setting it as the `src` of our invoked service. A callback handler is a function that receives the current `context` and the `event` object that triggered the invocation. This function returns another function that receives two functions as arguments. A `callback` function to send events to the parent machine, and an `onEvent` function for the handler to respond to events sent to the handler.

The way events are sent to the callback handler is by utilizing the `options` argument of the `send` action creator. We identify where we send events to using the `to` property, and setting the value to the `id` of our service.

Invoke Callbacks to Send and Receive Events from a Parent XState Machine

Trying to structure the state logic of an application as a single machine can begin to become unwieldy when we have too many states. It is often better to divide our app into smaller machines and invoke those machines as necessary.

When we enter a state in a machine, we can invoke a child machine. This machine can send and receive events from the parent. When the child machine reaches a final state, the `onDone` transition is taken by the parent's current state node.

To invoke a child machine, we use the `invoke` property and set the `src` property to a machine. We can forward events in the parent machine to the child machine by setting the property `autoForwards` to `true`. We can also send events to the child machine through setting the second argument of the `send()` function to `{ to: 'child-machine-id' }`.

The child machine can send events to the parent machine by using the `sendParent` function. In this way, parent and child machines can communicate.

Invoke Child XState Machines from a Parent Machine

Can you walk and talk at the same time? If so, you've experienced what it's like to be in two states at the same time. Hopefully, those two states have no influence on the other. Whether or not you talk, you can walk, and vice versa. States that occur concurrently and have no affect on the other are known as "parallel states".

Parallel states happen simultaneously. The machine is in _all_ of the parallel states at the same time. To create a parallel state node, we set the `type` to `'parallel'` and then remove the `initial` state. There's no need for an `initial` property when you're in all the child states at the same time.

Multiple Simultaneous States with Parallel States

Enumerating the possible states of a function is a sound way to write a function, but it is imperative and could benefit from abstraction. We can do this with a state machine.

A state machine formalizes how we enumerate states and transitions. For the sake of clarity and to emphasize the core concepts, I will be overly verbose with my code in this lesson.

In this lesson, we'll replace the state enum with individual state objects. We'll also replace our events `toggle()` and `break()` with events `TOGGLE` and `BREAK`. I'll also demonstrate the usefulness of the Machine's `initialState` getter and the `transition` method. Lastly, I'll show what happens when we pass erroneous states or events into our machine.

Replace Enumerated States with a State Machine

XState provides the `send` function to create an action that will send the event passed in to the machine. If we provide the second argument to the `send` function, the `options` object, we can send the event `to` a particular machine. This is useful when you have invoked a machine as a service on a state node, a concept that will be explored in a later lesson.

Send Events to the Machine with the XState Send Action Creator

Not all transitions should be taken immediately. Occasionally, we would like to conditionally take a transition. We do this through the use of "guards". A "guard" is a predicate function (a function that returns a boolean) that is set on a transition object's `cond` property (short for "conditional").

When an event is sent to the machine and it encounters a transition object with a `cond` property set to a guard function, it will call that function with the current `context` and `event` object. If the guard returns `true`, the transition will be taken, otherwise, it will attempt the next transition for the event, or remain in the current state.

```javascript
//...
EVENT_NAME: {
  target: 'state-name-of-transition-target',
  cond: (context, event) => predicateFunction(context, event)
}
```

Conditionally Transition to States with Guards in XState

It is considered best practice to use the string shorthand for actions, guards, and more when configuring an XState `Machine`. We do this by providing a second argument to the `Machine` factory function: the `options` object.

On this object, we can define our actions, guards, activities, services and more. We then refer to the name of these functions with a string of the same name.

```javascript
//...
broken: {
  entry: ['logBroken']
}
//...
// In the options object
{
  actions: {
    logBroken: (context, event) => { console.log('yo I am broke') }
  }
}
```

Replace Inline Functions with String Shorthands

Welcome to my introductory course on State Machines and the XState library. This course is roughly broken down into three parts.

In the first part, we'll explore the problem state machines set out to solve. We'll take a problematic function, iterate over it until we understand where state machines come in and save the day.

In the second part, we'll learn all the fundamental concepts of the XState library: machines, interpreters, states, events, actions, context and guards. This will be a solid foundation for starting to use XState on your own.

In the final part, we'll explore more advanced uses of the XState library: hierarchical, parallel and history states, and invoking services such as promises, callbacks and other machines.

My hope is that course teaches you what you need to get started with state machines in your work today.

Thank you for watching and enjoy the course.

Course Intro and Overview

Jotai has a primitive and flexible API, because of this it's up to you on how you manage your state within an atom. 

Sometimes your state is complex enough to warrant a sophisticated library for safer abstraction. This is where you can install xstate to your application and Jotai will work seamlessly with the state machines that you define using `atomWithMachine`.

This allows you to consume the machine like any other atom in your components with `useAtom`. 

As an added bonus, I'll show you how to use xstate's visualizer to develop and interact with your state machine in dev tools. 


Topics

Instructors

Content Type

XState