Modelling using statecharts changed my career as a dev. Of all the state management solutions I’ve tried, it feels the most complete, logical and robust. Even if you don’t use them in your app’s code, statecharts let you break down complex features into states, events, services, actions and guards.

We’re excited to announce the public beta of the Stately Editor! The Stately Editor is a tool for creating and editing state diagrams. We’ve received a lot of great feedback from the private beta testers, and now we’re delighted to share it with everyone.

Try the Stately Editor beta now

XState and TypeScript are a match made in heaven. TypeScript gives you type safety, and XState gives you logical safety. Together, they give you confidence that your code will do what you expect.

However, we’ve been hearing from the community for some time that the experience of using TypeScript with XState needed improving.

Today's your lucky day. XState’s TypeScript experience just got an enormous upgrade.

Last week we asked our community, “What are the biggest benefits you’ve had from using state machines?”

At Stately, we’re obviously fans of state machines. Still, we wanted to ask our community the benefits they’ve experienced, whether they were working on a specific project or incorporating state machines into their everyday workflow.

Last week our question of the week was “how do you convince your teammates to use XState?”

One of our most frequent requests for the documentation is more advice on how to convince others to use XState. Many people read an article, watch a talk or participate in a workshop about XState and are sold on using XState themselves. But when it comes to getting their team on board, they often need more.

Statecharts are a visual language used to describe the states in a process.

You may have used similar diagrams in the past to design user flows, plan databases or map app architecture. Statecharts are another way of using boxes and arrows to represent flows, but with XState these flows are also executable code that can be used to control the logic in your applications.

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.