At Stately, the Actor Model is one of our favorite programming paradigms, and we think it’s for good reason! The actor model allows developers to build reliable message-based systems by using actors to communicate. This works extremely well with state machines and statecharts, which can also be modeled as actors and can communicate much in the same ways. Read on to learn what the actor model is, the problems it seeks to solve, and how you can use it in your projects to communicate reliably across different entities.

We’re excited to announce the v5 beta release of XState and related packages after many years of development.

Sometimes you want to share a machine with descriptive details or comments, so we’ve added annotations to Stately Studio.

Tomorrow is part four in our popular Stately Stream series, where we are modeling a semi-complex client-side app using XState, Stately Studio, React and TypeScript. You can catch up on the previous videos in the series below or watch all our past videos in our Stately Streams YouTube playlist.

Two weeks ago, we had what some have called our “best office hours yet.” We introduced a whole bunch of new features and improvements to Stately Studio, including state.new with our new starter machine, annotations, embed mode, and version history. We also gave the first peek at our most significant editor update to date; we call it “codename: blocks,” check out the video to find out why!

It’s been more than six months since the release of Stately Studio 1.0, and we’ve been busy working on Stately Studio and XState. Here are some of the highlights:

Our top priority at Stately is to make it as easy as possible to create robust app logic in the form of state diagrams. That’s why we’re constantly striving to remove any potential barriers.

Today we’re happy to introduce another pro feature for our Stately Studio subscribers; Version History. With this feature, you can save versions of your work as you go and refer back to them in the future.

Are you looking to take your team collaboration to the next level? Do you want to explore the features of Stately and XState to their fullest potential? Then book a live demo with the Stately team!

Last month, Anders showed you how you could import a machine from GitHub by changing the GitHub URL in the browser’s address bar. We’ve added more to our GitHub integration. Our Pro users can now import all the machines from a repository into a Stately Studio project with the Import from GitHub button.

Today we’re happy to introduce another pro feature for our Stately Studio subscribers; import machines from GitHub. With this feature, you can quickly visually machines in any of your GitHub repositories. You can even import the machines to the Studio and keep working on them here 🎉

React developers often need to share state between components. While the useMachine(...) hook provides a convenient way to represent local state as a state machine, it’s not very feasible for shared or global state. Thankfully, @xstate/react’s createActorContext(machine) function, released in @xstate/react@3.1.0, is a convenient way to share state machines globally in any React application.

Happy 2023! The Stately team is back from their first off-site of the year in Lisbon and excited to get started on our plans for this year. We thought we’d kick off the year with a reminder of all the features we’ve released since the Stately Studio 1.0 release in October. It’s been just three months, and we already have so much to share.

The time has finally come; our new docs are ready to share with you all. If you’ve been following our office hours, you know I’ve been talking about these docs for a long time. Thanks to Anders, who used Docusaurus to build us a rock solid easily-maintainable platform with search that actually works, and the whole team, who have contributed reviews, explainers, and examples to get these docs started.

We have introduced a new feature to the Stately Studio, a feature we hope you’ll never see. Let’s call it machine restore, for lack of a better description.

One of our most-requested features has just landed in the Stately Studio; you can now import your machines from code!

Watch import from code in action in our latest video.

Importing from code is handy if you’ve already built machines while working with XState, or have created a machine using our older Stately Viz and haven’t yet tried the Stately visual editor.

It’s been just over a month since we released Stately Studio 1.0, and the team has barely slowed down! We’ve got more features live in the Studio today and even more planned before the end of the year.

Watch a demo of these features in our release video.

If you’re new to the Stately Studio, state machines or statecharts, we have the videos for you! Our new Stately Studio tutorials playlist on YouTube features bite-size videos to help you get started with understanding statecharts and state machines, and start modeling in the Stately Studio.

We’re excited to announce the release of Stately Studio 1.0! 🚀 Our mission is for all app logic to be visually collaborative and accessible to your entire team, and we’ve been working hard to make that a reality.

The Stately team has got some huge features to share with you soon. We’ve been working hard through the summer, which is why we’re already halfway into September by the time I’ve gotten around to this update post.

Farzad and David add more features to their resizable panel using XState and React. Watch Part 1.

Check out the accompanying code on Code Sandbox.

Farzad and David use XState to build the logic for a resizable panel with React in an impromptu live stream.

Check out the accompanying code on CodeSandbox.

Watch part 2.

From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much.

Thankfully, there is a science (well, math) to side effects, formalized in state machines and statecharts, that can help us visually model and understand how to declaratively orchestrate effects, no matter how complex they get. In this talk, David ditches the useEffect hook and discovers how these computer science principles can be used to simplify effects in our React apps.

Using the XState extension for VS Code, you can create a state machine in seconds and edit the machine using our visual editor. Use the xsm snippet to quickly generate the code required for your state machine, then drag and drop inside our visual editor to rapidly model your machine.

Updates to our VS Code extension​

Our XState VS Code extension has now been installed 10k times! Install the extension yourself from inside VS Code or find the XState extension on the Open VSX Registry to enjoy the following new features.

Are you a React developer using XState to model your application logic? Perhaps you’ve heard of XState but have been looking for an easy way to try it out in one of your projects. If so, then I’d like to share with you a pattern I was introduced to when first diving into codebase at Stately, that of using custom machine hooks. This lightweight, reusable way to integrate XState into React components is a delight to work with and I think you might like it as much as I do!

On top of our usual minor improvements and bug fixes, we’ve got great new features to share with you in July!

XState can be used wherever JavaScript runs, whether on the backend or frontend. Because the code it creates can be visualized, it’s great at handling complex use cases - being able to see what a complex piece of code does can be extremely useful.

Let’s look at each use case one-by-one.

Our latest update to the XState VS Code extension has made it easy to enable file nesting for typegen files. But what is file nesting?

We’ve had a busy month and have plenty to share with you this June!

What’s new to XState and Stately for May 2022?

A few weeks ago we uploaded a new video to the Stately YouTube channel showing how you can build basic video player functionality using XState and Stately tools. You can watch the video below or use the chapter links to jump to the chapter you want to watch.

This week we’ve added our Roadmap to the XState documentation.

Many of you have requested a roadmap to help you determine if it’s the right time to integrate XState and Stately tools into your team’s workflow. We’ve added a simple Roadmap so you know what we’re currently working on and what features are coming up soon.

We’re hiring for a frontend engineer, backend engineer, developer advocate and product designer at Stately. You can check out the Careers at Stately page on Notion.

Happy Wednesday! Time for our first Editor Changelog blog, where we’ll talk about the new updates we’ve shipped in the editor.

Last week we launched the new Stately homepage, which we hope will make it easy to understand what Stately and XState are and help you convince your team to use state machines.

You can watch us talk about the new design and its implementation during last week’s office hours. I’m particularly impressed by David’s SVG arrows!

If you use VSCodium, Coder, Gitpod or another editor with VSCode-compatible extensions, you can now install the XState VSCode extension from the Open VSX Registry.

Around a month ago, we released TypeScript Typegen - an enormous upgrade to the TypeScript experience for XState.

We’ve had a great response to it so far, but it’s only been available for VSCode users.

Until now. With our new XState CLI, you can get Typegen from the command line.

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.

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.

I wrote a form library once.

Once.

It was called React Redux Form, and using Redux for forms was a good idea, at the time (don't use it). In fact, my library was written as a response to Redux Form, and both libraries soon discovered that the idea of using a single global store to store all of your application state is a really, really bad idea.

When all of your forms live in one single store, state is easy to manage at first. And then, every single keypress starts to lag. It's a terrible user experience.

Redux is fantastic.

Some of you might disagree, so let me tell you why.

Over the last few years, Redux has popularized the idea of using message-passing (also known as event-driven programming) to manage application state. Instead of making arbitrary method calls to various class instances or mutating data structures, we now can think of state as being in a "predictable container" that only changes as a reaction to these "events".

XState version 4.7 has just been released. This is a minor version bump, but a major reworking of the internal algorithms, a lot of new capabilities, bug fixes, and a better TypeScript experience. It also paves the road for even more utilities, like @xstate/test and @xstate/react, as well as compatibility with other 3rd-party tools across the ecosystem, and even across languages.

I’m going to start this post with an excerpt from the book “Constructing the User Interface with Statecharts”, written by Ian Horrocks in 1999:

User interface development tools are very powerful. They can be used to construct large and complex user interfaces, with only a relatively small amount of code written by an application developer. And yet, despite the power of such tools and the relatively small amount of code that is written, user interface software often has the following characteristics:

• the code can be difficult to understand and review thoroughly:
• the code can be difficult to test in a systematic and thorough way;
• the code can contain bugs even after extensive testing and bug fixing;
• the code can be difficult to enhance without introducing unwanted side-effects;
• the quality of the code tends to deteriorate as enhancements are made to it.

Despite the obvious problems associated with user interface development, little effort has been made to improve the situation. Any practitioner who has worked on large user interface projects will be familiar with many of the above characteristics, which are symptomatic of the way in which the software is constructed.