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

It can be tedious to create a paired success and failure event for each external action that a state machine triggers.  Instead xstate can integrate directly with a promise and respond to the resolve or reject status of the promise itself.

Invoke an XState Service when Entering a State

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

Activities are continuous, ongoing side effects that are triggered by entering a particular state, and only stop when that state is exited. In the example in this lesson, we have an alarm clock machine that does the activity of beeping for the duration of the `alarming` state.

Activities are a function that receives `context` and the `event` object (just like actions). They fire off the ongoing side effect in the body of the function, and optionally return a function that performs any cleanup necessary for the activity.

```javascript
{
  activities: {
    beeping: (context, event) => {
      const beep = () => {
        console.log('beep!')
      }

      beep()
      const interval = setInterval(beep, 1000)

      return () => { clearInterval(interval) }
    }
  }
}
```

Use Activities in XState to Run Ongoing Side Effects

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

Transitions come in two varieties: "external" and "internal". By default, a transition is considered external. This means that a transition will _exit_ the current state node, and _enter_ the next state node (even if that state node is the state the machine is currently in). This exit/enter loop will trigger any actions that are set on the `exit` and `entry` properties.

A transition can be set to internal, either through setting a `.` (dot) in front of the state node name (as we do in this lesson), or through setting the property `internal` to `true` on the transition object.

When a transition is internal, it will not exit and enter the state node, which means that the actions in the `exit/transition/entry` loop will not be called.

Use Internal Transitions in XState to Avoid State Exit and Re-Entry

It is often useful to identify conditional branching in your machine as a state itself. A state that is designed to determine the next state does not need a specific event sent to trigger the transition. Instead, we can use the "null event" to trigger an immediate, transient transition.

The null event is identified with an event name of an empty string `''`, and is immediately sent to the state upon entry. We can setup multiple targets with conditionals, or fire off actions to set up a future state with this transient transitions.

Use XState Null Events and Transient Transitions to Immediately Transition States

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.

XState

Search Results