# The State of XState

Canonical: https://davidk.dev/talks/the-state-of-xstate/
Video: https://www.youtube.com/watch?v=Q05jcu9N98g
Speaker: David Khourshid (@DavidKPiano), creator of XState
Type: Conference talk · Event: React Finland 2021 · Year: 2021 · Duration: 18:37 · Views: 1970 (as of 2026-10-19)
Topics: XState, State management, Visual modeling, State machines, Statecharts, Actor model

## Summary
Over the past few years, state machines, statecharts, and the actor model have proven to be viable concepts for building complex application logic in a clear, visual way with XState. In this talk, we'll take a peek into the future of XState, including new features in the next version, and new tools and services that will make it even easier to create and collaborate on state machines.

## Key takeaways (quoted from the transcript)
- I've talked about XState and state management, state machines a lot in the past and in the last year, a lot has happened. (0:00)
- All those, I feel like all of those fit into the state management bucket, and what I mean by state management is these are all really good libraries. (2:00)
- If you're using XState with TypeScript, I highly recommend you use create model because we also have some new things and improvements coming with create model in the future. (4:00)
- We don't have to build specific integrations with every single popular library out there, everything is just an event. (16:00)

## Chapters
- 0:00 Introduction
- 4:00 Let's say you have schema for actions or events
- 9:00 Rather, we want you to have your documentation be completely in…
- 17:00 We were thinking like, Redux's idea of having a global store…

## Transcript
[0:00] All right, thank you. So, I am really excited to be here or not at Finland. I really wish I was at Finland. It'd be a lot more, cooler than it is right now over here in Florida. But I want to talk to you about the state of XState. I've talked about XState and state management, state machines a lot in the past and in the last year, a lot has happened. But before we get into the state of the XState, I sort of want to talk about the start of XState.

[0:00] And where exactly it came from? So, it all started like, I, I want to say, like, back when I was a junior developer and I was working for a medical company. Making a lot of complex forms, and these were forms where it's like you had to show specific fields when the checkbox is checked. And then, depending on certain conditions, it might take you to different states or different steps in the workflow.

[0:00] Or, you know, just invalidate based on async logic. And we weren't using any state management libraries or any frameworks at all. This was back in the time when Angular was just starting to become a thing, and Backbone was the most popular library, but we weren't allowed to use any of those. So, then I started researching, okay, there's got to be an easier way to do all of these flows, and I think in a very visual way.

[1:00] So that's when I started, researching state machines. And I saw that. It was a visual language and I was really interested by this because the flow is very easy to follow, at least for, you know, me as a visual learner. But then I decide, like, Okay, this is very useful, but they're a little bit too limited. So that's when I started, looking up. Statecharts and statecharts are an extension of state machines, and in a couple days there's going to be a bunch of talks explaining what state machines and statecharts are.

[1:00] But they're basically a visual way of modeling your application logic, and I found that state machines and statecharts are really cool and useful for modeling the behavior of parts of your application. But it's all about modeling the behavior. And not necessarily how different components and things can talk to each other. So I realized that the actor model, which I later researched, that, that, and state machines actually fit together pretty well. And so all of these combined really make up XState.

[2:00] Um. And so when you talk about state management and think about other seat management libraries like Redux, Mobx, UX, or even up and coming ones like Recoil, Zostan, Jotai. All those, I feel like all of those fit into the state management bucket, and what I mean by state management is these are all really good libraries. For. You have a store for your states, and you want to manipulate that state somehow, and you want to do it in the easiest way possible.

[3:00] But there is a need for what's called state orchestration, and so state orchestration is more about, like, not only state management, but determining how your state can transition over time. And what are the behaviors at each of those different points in time, and how do the behaviors change due to events? And so that's where X8 comes in. And so actually gives you the ability to know not only what happened and how your state changed, but how your state will change in the future.

[3:00] By mapping out all the possible transitions, states and events that can happen. [Music]. So, fast forward. A few years later, I open sourced XState in 2015.. Back at that time, it was known as Estado, and I guess almost six years later, you know, now X data is used at many companies around the world. Which, I'm excited about. I. I came from Microsoft, but I actually wasn't involved with any part of Microsoft that used XState.

[4:00] But it's really cool to see that they were using that in production.

[4:00] But this talk, since I only have 15 minutes, is mostly about what is new with XDA, what's new and what's coming up. And so the features I'm really excited about that are actually brand new and available today for you to use. One is strongly typed models, so we introduced this, this helper function called creates model. Where you give it the initial context and events, and these are event factories that creates event objects for you and so.

[4:00] Instead of calling create machine alone, you call the model dot create machine. And now you're going to have all of your events strongly typed, you're going to have your context strongly typed, all without having to, you know, do that really? Repetitive TypeScript logic and putting all of those generic types everywhere. So if you're using XState with TypeScript, I highly recommend you use create model because we also have some new things and improvements coming with create model in the future.

[5:00] Another thing I'm excited about is, the fact that state machines are a bit of a learning curve. And a lot of you are really used to using reducers, and so now with XState, you can actually get. Use that same logic from your reducers, put it in from reducer and spawn reducers. Or invoke them as actors directly in your state machines so you could reuse the exact same logic and customize it however you want to do.

[5:00] And so reducers are really useful, and these actors are really useful for if you already have existing logic and you want to incrementally move to XState. Now. Some upcoming features, which are currently in PR right now, the first one is strongly typed actions. So you might notice that we have a new property here called schema. And this allows you to create a schema. Either just the type. Or you could put some, you know, values like JSON schema in there, too, and present that as schema to the machine.

[6:00] So that, in this case, all of your actions can be strongly typed. Now, you could do the same thing with events context in the future, with guards and services too. And so the schema serves two purposes. The first is for strongly typing all parts of your machine, which allows for auto complete. And, in early error detection and things like that. And the second part is, especially if you use JSON schema, you could read that schema in runtime.

[6:00] So let's say you have schema for actions or events. You could automatically generate, for example, forms from that JSON schema based on your machine. And so this opens the door to so many exciting possibilities. So I'm excited to get actions in the rest of the schema in there pretty soon in version 4.. Another one that it's a. Really small change, but I'm really excited about. It is, determining whether you could send an event or not.

[7:00] Before, we used to have to duplicate, validation logic, and, disabled enabled logic, uh. And what we're really trying to do when we're disabling a button or disabling a field is saying, I want to disable this. If sending this events will not cause any change, because it shouldn't cause any change. And now it's going to become a lot easier with State..Can. You could just say, Hey, if I send this events, will it change anything?

[7:00] If not, then maybe this button should be disabled. So it's just a really easy way to have that improved, both developer and user experience over there. And one of the biggest changes, too, that's coming up soon, is deep actor persistence. So with X8, you could persist and restore states, but with XD you could also spawn actors. And so, again, in a couple days there's going to be a talk on the actor model.

[8:00] So in, coming up in next day, we are actually going to be able to persist these actors. So that when you restore your machine, states like, let's say, you refresh your browser window or come back to it after pulling it from local storage. It's going to attempt to rehydrate each one of those actors at the states that they were persisted. And if you're not able to, then it will just start the actor as new and everything will still work as normal.

[8:00] So that's one of the big features that's coming up, and it's one that's been highly requested. So, the XDA ecosystem is currently made up of a lot of modules, especially integrations with frameworks like React, Vue and Spelt. And helper. Utilities like FSM test for model based testing, graph, which is used to power a lot of our visualization and testing utilities. And inspect, which allows you to communicate your state machine running in your live application directly to an inspector.

[9:00] We do have a few upcoming modules too, and so, we and these.

[9:00] These are preliminary, but one of our engineers, Matt Pocock, is working on X8 Parser and XState CLI. So this is going to give a whole new set of static analysis abilities, to your state machines. And it's going to enable a lot of really cool things. And so three other things that we're working on, too, is XState, XDateForm, XA Router, and X8. Query for all of the common applications that you would, you would probably want to use a state machine for in your application.

[9:00] And these libraries are going to help making the creation of forms rather, in querying async data a lot safer, a lot easier, and, most importantly, able to be visualized. And this is all even before X8 version 5, which we're still working on. And a lot of big changes are coming there too, but not huge changes as in breaking API changes. But, more, just really, good quality of life improvements. One big thing, or rather, I should say small thing, is that X8 version 5 is going to be more modular.

[10:00] So instead of importing all of X8, you could choose exactly what you want to import. And so this is going to result in a smaller file size. There's also going to be higher order guards, which are going to allow you to combine different guards, whether they're serialized or in line. Inside of your machine definitions. And this allows the guards to be visualized in some creative ways as well. We're also going to be introducing partial wildcards so that you could say, if my event starts with mouse dot something, then, uh.

[10:00] Respond to it with this transition. And so this allows a lot more flexibility and succinctness in your machine definitions. But yeah, the other big things that I, I'm really excited to release, in fact, I'm publicly releasing them tomorrow. But you're the first to know about it is, first. Stately..ai slash viz. This is the new visualizer, that is a vast improvements to the old one. If you go to x8.js..org Biz, you're going to see that there's a huge difference between this and the upcoming Stately visualizer.

[11:00] So if you visit the visualizer, you can now enter your machine definitions in TypeScript, there's an entirely new layout algorithm for laying out all of the states. And now you could also share your machines in the Stately AI registry, so whatever you create in the visualizer, save it to the registry. And you're able to fork other machines or favorite them or. You know, just share them with people so that they could simulate your machines and understand your application logic just by sharing a link.

[12:00] And the final thing that we're working on and hopefully getting it out within the next couple of months is the Stately editor. And so hopefully we're going to be having a data coming out soon for this. And so this is going to allow you to create state machines visually without having to, to manually code them, or you can manually code them if you want. The main idea here is that we want you to be able to, not have to have both documentation and code be two completely separate things.

[12:00] Rather, we want you to have your documentation be completely in sync with your code. So that it's never out of date. Because that has been one of the biggest struggles from all the years I've been working in various projects. Is that we would have all of these nice, beautiful architecture diagrams and logical flows, and user flows and everything. But as soon as it gets to the code implementation, those flows quickly become out of date.

[13:00] And so that's something that we're looking to solve with the Stately editor and the suite of visualization and analysis tools that we're going to be introducing soon. And so, you could find all of this information at Stately..ai. If you, sign up for the mailing list and also please join our community at discord..gigi XState. And with that, thank you so much. React Finland yeah, thanks for the talk. Let's move on to the discussion and, see if you have any questions from this, international audience.

[13:00] So okay, first one, I guess, that's more for Ryan. Yeah, I mean, I talked to David a little bit and played around with it. I've got demos of it I haven't made. Like an official integration. Hoping to kind of play with a bit more the community, get an idea of what they want to see out of this integration. One of the cool things that we can do with solid is, apply the changes fine grains.

[14:00] So you can update a machine and then, like, have only certain properties, update certain parts of the DOM. So it's all like, split out automatically, without selectors. Or anything? So we still got some more research to do, but I'm looking forward to seeing, official integration. Yeah, cool, mate, like to talk? It was great, great, from my point of view as well. So now we don't have so many questions from the audience.

[14:00] I mean, one thing I was thinking about, is this? Uh? Like when you write an application, you write some logic? How much of this logic can be separate from the from React or solid, or of you or whatever you're using? So, yeah, that's really the main point of X8 is that your logic is completely agnostic. And we first had integrations with React, and actually that's the one that we spent the most time with, just because React.

[14:00] It's not exactly an events driven, framework or library, or whatever you want to call it, so you do have to do some workarounds for that. But yeah, we've seen integrations for views felt work really well. It works pretty naturally, actually, with spelt and Angular, just because it's a subscribable story and I'd imagine solid as well. But yeah, the entire point is for you to have your entire logic framework agnostic, and, in the future, language agnostic as well.

[15:00] Yeah, yeah, that's cool. And if I remember right, there's some kind of standard for state machines. So so just like you can get. I don't know if it's XML or whatever, but you can get some kind of definition out of it. And that, that's, that's what you can throw around. Yeah, exactly, it's called SCXML, which stands for oops, I mean myself, which stands for statechart XML. And, yeah. There's actually a lot of implementations in different languages, so whatever you create in XState in theory, can be run in different languages.

[15:00] Since it follows that spec. And I guess you have a lot of tooling around this, so when you have a standard and it's like, with this texting and other things, uh. And we have a question, does X type play nicely with other libraries like router or form libraries? Yeah, so the way that XD plays around with virtually any library is XD is. It's simple, and of course, simple doesn't mean easy, by simply means it's completely events driven, so events in state driven.

[16:00] Which means if you want to communicate with X8, you do so via an event. Now this could be, you know, a little bit of boilerplate where you have to convert everything. Especially if you're using it in React. You have to put it in useEffect. And whenever something changes in that useEffect, you're sending in the vents over to an XState machine. But what that means is that events, it doesn't matter where it comes from.

[16:00] We don't have to build specific integrations with every single popular library out there, everything is just an event. And so that's the way that it would work with React Router and other form libraries, and even libraries like React query, React 3 Fiber.

[17:00] I'm actually really excited to play around with that and make some games with that. But yeah, cool. More questions so will there be any improvements to manage global state machines in next state React without send parent? Maybe a used global machine hook? Yeah, that's. That's something that the Stately team has actually been thinking about a lot. Is, at first, our X8 was local component first, so you have used machine, which is just like useReducer, you put them in your individual components.

[17:00] But we were thinking like, Redux's idea of having a global store is actually useful because you do want data shared with a lot of components. But we don't agree with the whole single global store idea. So more. It's like a global system where you have stores that communicate with other stores. And so components can subscribe to any of those stores in the global system. And so, yeah, look out for that soon.

[18:00] We actually merged a PR recently, that's going to be an important fix to getting that working. Yeah, cool, next one. Does it make sense to think integrating excited with Mobex state 3, or are they overlapping solutions? I think Mavic's D3 is cool, and, there were some people who did look a bit. Look at integrating that with X8 a while ago. I'll have to experiment with it more. But I think what we're doing in XState very much mirrors what Mob X day tree is doing architecture wise.

[18:00] So there might be some overlap. You?