Building State Machines Using XState (Modern Web Podcast)

Hello everybody and welcome to another episode of the modern web podcast. My name is Rob O'Sell. Today, we're extremely excited to talk about statecharts and XState with David Khourshid. You might know him better on Twitter as David K. Piano. I think my heart was broken when I realized that wasn't his actual last name, that he has a different last name. But yeah, David is a software developer at Microsoft and the creator and maintainer of XState. So David, how are you doing? I'm doing great? How are you? I'm doing great now? I should say at the top that I was just joking with David that today's episode is a little bit of a lost episode. So we had a little bit of a snafu with, the recording from the previous episode. So this is actually David's in my second conversation, and we hope that you enjoy it even more than the first.

That you will ever hear. But before we dive into X data and specific, first, I just want to, give a shout out to one of our sponsors for today's episode. So today's sponsor is Syncfusion Essential. JS2 is a web UI component suite of SyncFusion that offers more than 65 plus modern UI components on all major web frameworks such as Angular, React, View, JavaScript, Asp.net core, Asp.net MVC, and Blazer. You can start to build and deliver the high performing and responsive web apps faster with great user experience, and you can learn more about this at syncfusion..com modern web. And I should mention, for anybody that's watching the video of this, this is one of their awesome swag sync Fusion shirts. So, thank you so much for sharing that with us as well, all right, so jumping in to, XState and talking about state machines and statecharts? This is something that has been really fascinating to me and a huge interest of mine for the last, several years. But you know, today, as we're recording, this is a kind of a big day as everybody is pouring through.

The state of JavaScript results and XState made it to the list. So, first of all, David, congratulations that you have made the state of JavaScript. That means that you're, you know, you've made it, you're famous now. Yeah, thank you, yeah. Last year, it was, a popular writing, I think, top 10, but then I guess we had a lot more momentum this year. And, yeah. So the one thing that I wanted to call out right is that, although it's awesome to make it, the biggest slice is still people that are unfamiliar with the library. So this is still something, a library that people are learning about, and it's being evangelized and people are finding that they love it. And that's that's why it's showing up on the list now. But there are still going to be a lot of people that are listening to us talk that are like, Okay, maybe I've heard of a state machine back in college, but I certainly never heard of XState. So could you give us a little bit of an introduction to kind of what is XState and kind of why you decided to write it?

Sure, so, XState is a library that allows you to make and implement state machines and statecharts in JavaScript. And a lot of people hear that and they think, oh, okay. So it's another state management library. There are some management libraries like Redux, Mobx, I guess Apollo clients. It, you know, had pretty good ratings in the state of JavaScript survey. But XC is a little bit different than that. Because it's not just state management, it's date orchestration. So it's more of a library for allowing you to precisely define how one. Once they can, you know, transition to another state, the actions or side effects that you could perform, and also the ability to spawn other sea machines. So there's a lot of things going on in XState. That actually makes it quite different than the other state management solutions out there. But, in short, it's a way to, to use state machines and statecharts in JavaScript.

Yeah, you know, one of the places where this just it snapped into place for me. Because, honestly, as I mentioned, you know, I went to college. I had a computer science degree in college, so I remember learning about statecharts. I was also an electrical engineer. I think you had a similar background. Oh, no, okay. Sorry, I was talking to someone else then about space.

Play from 0:00

Arts. And we had this conversation that this is a big part of, electrical engineering and computer engineering curriculum. Is talking about kind of how, how to do this sort of binary edition and statecharts, and kind of how a lot of that, falls down from. You know, the way that our computers are built these days. And I, I'd always sort of just left it there. I never really thought much about it. Until I had started to see Ryan Florence talking about building reach UI. And he shared a statechart at a state machine that he was working on for a tool tip so you think, like a tool tip, maybe one of seemingly one of the simplest concepts ever. You hover over something and then a box appears that describes it. How complicated is that? You just need one boolean, shown or not shown, right? Like? And what he displayed was that there are so many different types of inputs, whether they be touch inputs or hovers or tabs.

And you need to account for animations, for hiding and showing. And if something's fading out, you need if somebody goes back to it. You want to instantly show it again and maybe not fade it in all the way. And it was an elaborate statechart that covered a lot of, of cases, and you didn't have to read the code that turned into. And I just thought that was such a powerful illustration of, of these tools. I mean, I don't know if you have any other examples that spring to mind where people don't expect these things to show up, right? And I think that's actually a great example. Because, you know, logic spans a lot more than just a boolean value. Another classic example I'd like to give is, fetching data. A lot of people are completely satisfied with a nice is loading variable, it's either loading or it's not.

So what I typically like to ask is, what does is loading false mean? Does it mean that the data already loaded doesn't mean that the data didn't load yet? Does it mean that an error happened? Like, there's so many possibilities, and the typical solution is just okay, add another boolean value. And so this just goes to show. That the logic that we put in our computer programs is just orchestrated by all of these boolean variables like that. That's a natural way to do it, and we have a lot of IF statements, like just trying to organize logic. But because of that, it's not clear what your software can do, the features aren't clear, the logic isn't clear. And so that's what state machines and statecharts purports to solve. So, yeah, that's a good example, though, with the tooltips, yeah, I think. He went on further to describe that they had some additional conversations for accessibility purposes about what would be the right way to handle something.

And when they decided that, they needed to make an added additional state and an additional transitional state. I think it was for animation purposes, they were like, we just added the extra state to the state machine, no code changes and it spun right up. And I think that's maybe one of the other selling points is that, you know, I. So often people throw around the terms functional and imperative, and I or declared, excuse me, an imperative. That I don't know that the terms really have as much meaning anymore to people. But in some ways, I feel like this is echoes of that conversation. Where the power sometimes of these state machines is that you can sometimes make pretty complex changes. Pretty simply by adjusting some of these transitions or the guards for those transitions. Without having to go and find all the places in your code where you would have had checks and protections against that, that state and fitted in, right, yeah, and that's, because, like, as much of a learning curve as state machines and statecharts are, it's really just a simplification of everything into what's called a directed graph.

So, you know, with a graph and graph theory. You have nodes and edges, so the edges are the arrows between the nodes. And with the state machine or statechart, the nodes represent different states. Now, something that's also a directed graph is a well, a map. Like, let's say, you need to get from point A to point B, right? So just like the example you were talking about, you would say, you know, just put it in Google Maps and it'll find. Me a nice, straightforward path from my house to wherever I need to go. But let's say that you need to do something else, like you need to pick up groceries, or, you know, visit the friendship. Well, maybe not right now because it's coveted times, but, you know, do something like that then. Like the routes, the, you know, the mapping between the routes don't change. It's just okay. We have a little detour here and then we go to the, the final seat that we have to be in.

And uh. So, state machines and statecharts provide that underlying language of your application. Logic is just a directed graph. If you want to add a feature that's just a new node of maybe a couple new transitions, if you want to change the feature, that's just changing the transition. So it's like, just like everything is made up of molecules, and, you know, atoms, everything in software is made up of states, events and transitions.

Play from 4:00

You know, it's funny because to me, that's why I've never fully understood the comparison between XState and in libraries such as Redux. I think you're right when you pointed it out earlier that is, this is one way to manage state. XState certainly is that, but I've always seen XState as being more analogous to a library such as, RxJS. So something that more looks like transforming events into observables and that sort of like, higher level consideration of just taking all the various inputs into your system, sort of ordering them as these streams and being able to get that kind of control over it. That the sort of much more declarative definition of, kind of how you want to react to stimuli. From your, from your from your toolbox, from your, from your UI, from your users. And I always thought that was just a much closer analogy to XState. And I thought that maybe the two libraries even would make a pretty good pairing. And a lot of systems. But I don't know what your thoughts on that like.

Do you enjoy? Kind of people asking, should I use Redux or XD? Or, you know, do you kind of feel like that's sort of asking the wrong question? No, it's actually not. So much the wrong question, there's, you know, I. I've been meaning to make like an alignment chart, or like a sort of graph of like just the different. State management libraries. But, I think that in terms of two axes, I think of it in manipulating states directly, which is libraries such as MOBX, Recoil, you know, just libraries like that. And managing state with events which would be closer to Redux and XS, and that's why I actually see that Redux and X8 are pretty similar. But then there's also the topic of having a single global store versus multiple global or multiple stores. That each communicate with each other, and they could create each other, things like that. Redux is very much in the single atomic global store camp. And XD differs a lot.

By, you know, allowing it to be used, you know, at a component level, or having a system of many stores that communicate with each other. So there's a difference there, uh. With regards to RxJS, there's similar, similarities too, because RxJS can be thought of as a stream of events, and what those events are, you know, loosely defined. They could be, you know, things such as just value changes or even explicit events like you would have in Redux, uh. But RxJS is much lower level than XState, in that you could use something like RxJS to build an XState. And in fact, X data is fully compatible with RxJS. Because, this, the um. The interpreted machines are subscribable. So they're observables really, and so, you know, you could use them together. But, RxJS is just the streams, just the plumbing, and it's like LowDash for those observables. And X8 just uses that concept of a stream of events and, you know, adds some structure around it.

To be honest, I think that's part of the reason why XState is taking off so well. Is that, you know, it's been said, or it is true that? State machines are not new, right? This is a concept kind of almost as old as computing, in some cases older than computing, depending on how you define it. So, you know, state machines are not new, and they're certainly not even new in software development. Other. Disciplines, other languages, other ways of building software have done this forever. But what I think is so exciting. I think why this catches on so well with people is that it does hook in really nicely with all the frameworks, right? So because it's observables, it hooks up super nicely with Svelte and Angular. It has library bindings for React and for view, which kind of makes XState. And then you can just choose to do it yourself, either in vanilla mode or by integrating into these libraries itself.

So, you know, I don't know if you want to speak to that a little bit about just how it's been. I don't know if this was intentional, on the way that you've designed things, or whether it just works out that it just fits really nicely into the existing models of the other frameworks that people are using right now. Well, yeah, you probably know that I, I used to be really huge, and actually, I still am really huge. On just observables, right? Just this idea of a stream of values, like, I think that promises are not sufficient, because promises are like, you might get one of that one value eventually, and observables represent there's many possible values that you could get over time. And so I'm like, all programs can be described closer to that idea. Like just things change over time and you get this like stream of values. So frameworks such as felt, naturally play well with this.

And in fact, I was really excited to see spelled so high on the charts in the state of JS survey. I played around with it a little. In fact, I made a template for XState and Spelt, and I didn't even need to write a custom hooker. Actually, I think I did, but it was like, very, very thin. It just plays really well with, Spelt's doors, because, you know, it, Spelts naturally operates on that reactive principle. So, yeah, uh. Like the way I designed X8 was actually with no framework in mind. In fact, when I first created XState, it was not even meant to be used for anything. I was just playing around with, all right, how can I describe statecharts with, you know, just with JavaScript, regardless of framework? And then, you know, it didn't come until later that I thought, like, maybe I should start writing some integrations for these frameworks.

The most painful one was reacts, React. Has some funny things going on with hooks. But yeah, and Angular, actually, because X8 services are observable, it actually, integrates pretty well with Angular without any extra tooling. Yeah, so even if it was just an accident, it certainly is a happy accident.

Play from 9:00

I think again, that's why people just, they just, you know. I think any time it's difficult to integrate a new library, people kind of go. It's really going to have to prove itself. But when it just slots in, people looking like, Oh, I'll try a bit, I can, I can play around with it a little bit. So, you know, thinking about, people. So we talked about people that do the is loading, is, is loading, is errored, and then they'll, like, say, Okay, well, error maybe take precedence over loading. And I'll code that into my template logic, and I'll try to make sure that all these things stay in sync and all of that happens. But I think one of the things that people have been advocating, that have sort of been pushing for. Either XState or just state machines and statecharts in general is okay. At a minimum, make 2021 the year that you stop using the booleans. Let's switch over at least to using sort of enumerations.

And so I think a lot of people have been moving that way to just to. You know, if you're not going to do a full-blown statechart or full-blown state machine, at least just at least just code the states in enumerations. But when people are kind of going, okay, great, I got rid of all my booleans, I have my enumerations. What is the next step for these people? So they've they bought in, their team loves it, you know what? What is the next step in the direction of state machines? For them? Like, what is the problem they should be looking out for, what is the thing they should be keeping in mind? That's an indicator to them that they might want a hardier solution, or to take the next step in their adoption of statecharts, so. Using a news instead of booleans is the finite state part of finite state machines? However, like, defining all of these different states is sort of, I don't want to say useless, but it's less useful.

Without having a, declarative way of defining how you could go between those states, right? It's sort of like, saying, you know, there's all these countries in the world, but if you don't have a way to travel between those countries, and you know, what's the use, right? So, yeah, the next thing would be like just defining those transitions, and normally in code, you would do this in sort of an ad hoc way, like you would directly set the states. But then, you're copying logic all over the place with that, and it's sort of a messy approach. And so that's why you would have switch statements. And this is something that I'm actually really glad that Redux popularized is the fact that your state and your logic for changing state is within a single reducer. So when you receive an event, only that reducer can tell you what the next state is going to be.

So the logic is centralized. So that's a good approach, you know? Using switch statements, I would say, on top of that, you would, use switch statements on the finite states, not the events. The typical way of doing things in Redux is switching on the events type, and with Xtape you can think of it as switching instead on the finite states, and then the events type. And obviously, that's really verbose to type, which is why X8 has that object DSL. So, yeah, that would be. The next step is defining those transitions, and then you're pretty much most of the way there. Yeah, and you know, what I like about that is because that is why, I find kind of the modeling tool that X8 has. Like, if you've never used X8 in a library, just using the modeling tool to draw these state machines and using that in your design documentation, that's just a value-add period.

So if you're listening this and you're saying, I'm not allowed to bring this library in, somebody doesn't like it. And we just use the visualizer to draw these things and start putting them into. Your designs. People will start falling in love with them and then like, Hey, does this work with code? But I love this idea that you can define the transitions and then you could fire any sequence of events you wanted to. And the state guards, the transitions and the guards on them will just protect you. Like, it's that, it's that like that, the kind of sort of like item potency. Like the fact that you can just rest assured that no matter what sequence of things they're gonna throw at it, you, you have a predictable and readable model of what's gonna come out of it. As a developer, it reduces the complexity of what you're implementing.

So much to know. All I have to do is faithfully bind the state machine to the UI and the places I expected to find it. And I can just be confident the rest works. Because I took care of the hard stuff outside of the code, and I did the easy part in the code, the easier to test, easier to verify part. Right? Yeah, and well, what's funny is I was actually talking to some colleagues at Microsoft about this. But just the idea of like a framework agnostic component, right? And if you really think of what a component is, it's, you know. It's just a thing that is rendered based on the state. And it's also things that you know the user could do things to, so like, take a button, for example, you could click on the button, you could hover over it. Like, all of those are events, and so those events cause a change in state, and they might also cause like effects to, or like actions to happen.

Play from 15:00

And so, basically, your, your UI, and I mean, regardless of if you're using state machines and statecharts in the front and their back. And like. Just this idea that your programs can be defined as a sequence of events, like you said, it really, really simplifies things. So, yeah, absolutely, so okay. So now we've moved over. We're kind of using the FSM, so I think, you know, we didn't make reference to this, but I believe it's it's XState FSM. Is that accurate? The sort of the quote-unquote, no-frills version to just get? So the quick and dirty stuff in there, yeah, the flat version, so no nesting, no parallel states. Yeah, right, so far, that's kind of what we've talked about, right? And maybe that's as far as people have ever seen state machines. But the thing is, as with anything in life, it goes deeper. There are decades of scholarship about these things, and people have learned some really interesting ways to model some really complex situations using these statecharts. So I'm kind of curious, you know, I asked you earlier, you know? What are some of the things that people should be keeping in mind as they move from the simple enumeration to using a finite state machine?

But my next question is more along the lines of is, how do people learn what finite or what? What statecharts can do? And what X8 can do? When it's all the way turned on, you know, I think RxJS and observables was the same way a lot of people don't think in observables. So, watching Ben Lesh do podcasts or videos where he's like, watch. Let me show you how easy it is to do. Pull to refresh, and your mind just gets blown and you learn how to express yourself in this new, methodology. How do you recommend that? People sort of broaden their understanding of what statecharts are even capable of doing to inspire them? Maybe to know when they could be using some of these more advanced features. So one of the mistakes that I made earlier on my career is just trying to be like, Oh, here's this new library, like here's RxJS.

Let's try to learn all of the observables and see what's possible. But, that should not be the goal. Statecharts do have a lot of features, in fact, they're in extended formalism, on top of state machines. And so you have things such as a hierarchy with nested states, orthogonality with parallel states, history, broadcast, communication, etc. But you shouldn't be trying to learn all of those features. I would say, like, the important thing is just what you said, like learning to think in well, like, not in observables, but in state machines. And honestly, the simplest way to do that is like, once you learn what those three basic. Components are a state or finite state, an event and a transition. Grab a pencil and paper, grab a whiteboard, and marker starts drawing out your logic, and you're going to find out. It's actually really intuitive. So when you're trying to make a new feature, you're going to say, okay. So it could be in this dates, but then if the user clicks this, or if this happens, then it's in this date, and that's.

It has its own set of behaviors, and this other state has its own set of behaviors. You start drawing those out and you start, you know, just understanding the logic by just looking at the diagram, and then you just translate that to code. And so that's what I want people to learn, whether they use XData or another library, or even if they use no library at all. Like, just the idea that your application is made up of these state machines, and you should start thinking in terms of state machines, instead of whatever ad hoc logic we were doing. I, I can't even think of it right now because, like, I've been doing state machines for so long. That I. I look at old code and I'm like, why are there so many if statements and booleans like, I cannot understand this at all? So absolutely thinking, yeah, it. And it's one of those things that, once it clicks, you're not even to realize that it clicks. You know, I sometimes tell people like, learning languages, I like to joke that.

I learned I studied two languages when I was younger, and in one of them, I. It stuck with me and I said. It was because I got to the point where I could dream in that one and then the other one, I could only speak it. And I always use that as sort of as a joke. Is like, sometimes when your brain finally switches over to kind of be able to think in that other, that other way. It is really, pretty, pretty powerful. When you start seeing things from a different angle, and now suddenly problems that were sort of really difficult become really simple. Because you can break it down a different way. Yeah, and that's that's the thing that actually seems or seemed. The most unlikely to me with XD was that, you know, so many people were using it. I was completely expecting it to be a niche library for the longest time.

Just anyone who was interested in the same, you know, state machine, state charter niches, I was interested in, like that, academia, whatever, but it, it really is like that. Once you start thinking in state machines and statecharts, it's really hard to, you know, not see your logic in that way. And so, and that's why I like to joke that X8 is like Redux with rules, so if you didn't think Redux had, well, all right. So, X8 has considerably less boilerplate than Redux, but, X8 has also a lot more rules than Redux. And so if I were to advertise X data as, Oh, yeah, it's Redux. But you have to learn all these extra rules. In computer science terms, I, I don't see why anyone would adopt it. But you know, once they start thinking it, they're like, Hey, these constraints actually make sense for the logic that we're trying to do.

So, yeah, it's sort of a mind twist. And for anybody listening here, you know, because it requires a different way of thinking it, it shouldn't be confused that this is actually difficult. So what's interesting is that one of the libraries that I recommend that people use.

Play from 20:00

If their team is comprised of juniors, or has juniors on it, or any number of juniors on it is XState. And part of the reason for that is because. One of the things that I encounter a lot when I'm mentoring people that are more junior in development is that. Oftentimes, the questions they ask is, I'm trying to get, you know, Angular to do this? I'm trying to get this variable to be represented like this. And you always have to sit down with them first and go, no, no, okay, forget the framework. Just tell me in terms of what you see on the screen, what you want to have happen and in which scenarios you want that to happen. And then you talk through that and then you go, Okay, now let's find a way to bind that, or turn that into Angular code. And teaching people to think that way is a.

Really critical first step. And again, that's why I recommend this library to people. It's not an advanced library. It's actually kind of the opposite, it lets you take the. It helps you separate the syntax of the framework or the tool that you're using from the definition and the understanding of the business logic. So this is, even though it sounds heady, even though maybe some of the terms you're hearing, you're like, I didn't, I didn't take CS in college. Can I even get there? Trust me, this is an approachable methodology, it's an approachable library, and it might even be better for understandability than not using. And, it fact. I'll tell you some of the things I like doing with, XState. Honestly, I'm a really lazy developer, so, I like being lazy as much as I can. And so when I'm using XD to create logic, you, you have to add implementation details such as like, Okay, what does doing this action actually mean?

How are you going to call this service? Uh? But at the beginning, when I'm just designing everything, I just put a string, it's like, make websocket connection, you know, I'll just put it as a string there, and that's totally valid with, with XState. And so that's basically a placeholder of, like, here's where the implementation for this action goes. And so you, you could really be as lazy as you want with that state. Describe it completely as sex, in fact, completely as JSON. And then later add the implementation details. And this actually allows you to use, the exact same machine in many frameworks, because all that changes are the implementation details. The logic is the same, the actions might be a little bit different, but otherwise everything is still the same. So that's a perfect segue to a question that I've been curious about, and I, I don't know if I've seen plans for this.

Or, you know, I don't want you to spoil any announcements or anything like that. But another library I really love is Tailwind. You know, and one of the big cool advancements of Tailwind in 2020 was the release of Tailwind UI. So to this ability to share snippets of Tailwind code. That represents certain components that could both inspire people and. Speed people up. So we've talked about X8, the fact that this is sort of framework agnostic, also that they are portable, they don't rely on a centralized universal state machine necessarily. So, is there been talk about, like npm for XState, like an XState repository? Or a way for people to share or inspire others with kind of their solutions for typical development problems? Yeah, in fact, that sort of is the next logical step for, I. I have a website at statecharts..io. I, I made that website to sort as a placeholder for basically all the things that I want to create. With X8, the first one, the most major one being the inspector.

Which allows you to visualize your state machines in your live running application, either in a different screen or in an iframe, and you can see the machine working. And what's crazier is that you can even interact with that visualization and see things happen in the app. So it's sort of a two-way thing. But what I really also want to do is, yeah. Basically have that repository of just state machines that people can share and people can use within their organization or their teams. And customize to their needs. And, um. Like, for example, let's say that you're working on an app and you, you know. European tells you to add a dreaded drag drop feature to the list. And you're like, Oh man, like, all right, I'll try to find a library that doesn't all right. This doesn't exactly do what I need. We have a lot of custom things that we need to add. I, I want to be simple to just, you know, go to this magical statechart library, be like, give me a drag drop machine.

It's framework agnostic, so all I have to do is plug in. The events, read the state, and that's it. Like, in fact, that's the process that would work for pretty much any machine, you know, you send it events, you receive state, and that's how the machine works. And just be able to copy paste that machine right into your code and have it work exactly as you want. And then if you need to add anything custom, then you just add the machine. Because again, it's like we were. Talking about earlier, these are all just notes and edges connected to each other. If you want to add feature change feature, you're just moving arrows and notes, you're not doing anything crazy, and so that's something that I feel like is. The problem with a lot of libraries today is that they're not framework agnostic, they're either like purpose built for a specific framework. And also the features the things that the libraries allow you to do is very set in stone.

You could propose different behavior, but if it's accepted, best case scenario, that adds complexity to the library, which introduces a lot of bugs. And worst case, and most typical case scenario. The maintainer just goes like, no, I'm not going to support that. Go ahead and fork it and try to figure out yourself and that's not good. So, we do need a more extensible way of sharing logic, not sharing components, but sharing logic. Because I feel like that's the next step in, in, you know, web development programming in the future. I'm with you and I. I was gonna say the same thing. I love it because the one thing that I'm thinking about here is accessibility. Yeah, it's not that accessibility is unknowable, but it is very difficult for people that have never either implemented it, or never experienced. Or just don't remember experiencing any sort form of disability, right?

Because some disability is permanent and other types are temporary. And we might not even think about that, right? Like you break your hand and suddenly you have to type with your other hand or things like that. And so what I love about it is that you can share with someone that, that skeleton, that business logic, that interaction skeleton. That includes those hooks for accessibility directly into them. That you know that you might not even realize, had not even thought of, oh, what would this be like if somebody needed a touch interface for it? And so, you're right, not at the level of components. This would slot inside of any component library you're building yourself, or any component library that you're integrating into. I think that is going to be a huge win for a lot of people that advocate for developers doing things, that will make their users lives. Better, or just make their tools accessible at all? So I'm with you on just being excited for what people are going to be able to share with each other.

And what people are going to be able to enforce by sharing these sort of things. Like a state machine, yeah, and I, I completely agree with you, accessibility is not easy, and it's it's really, really important. Reach UI, has done a lot of work with components, with a huge focus on accessibility, and Radix UI, if you've heard of that from the team at modules, has done similar things. Just making sure all their custom components, like combo boxes, drop downs, whatever are all completely accessible. And they follow, you know, those WCAG guidelines. And, yeah, there's a reason that no one really does this when making custom components is that it's just really complex to do. And, the thing with Radix UI, and also reach UI. They both, at some level, also use state machines and statecharts, and they do that to basically make sense of the accessibility. And I, I know we tend to this might be biased, but we tend to think of accessibility in terms of, like, a, oh, well, you know, I don't even bother with that.

Like, I'm sure that there's a small percentage of people who need this, but if I omit it, then whatever, something I do want to emphasize and this is sort of off topic, but is it's that accessibility is for everyone. I know that I would be pissed off if I was typing in the form, I press tab and nothing happens, right? Or if autocomplete didn't work, or if clicking a label didn't focus on the right input. Or if I, if everything had to be done by mouse. I like being very keyboard heavy, so if I have to click everything, that's just really annoying. And actually, there was an issue. I had a MacBook Pro where the screen just wouldn't turn on, but I needed to, you know, do some stuff to it to fix it. And using, the, the screen reader technology actually saved my butt on that. So, in short, like, even if you're fully able, accessibility is for everyone, and it's something.

That's hugely important to focus on. Well said, yeah, anything that could make it more, available to people to help them learn. Because, again, I find that it's not that people, the majority of developers I spoke to, is not that they're opposed to it. They just never been taught it, and it's it's not something they can intuitively understand. Like many other types of things, so it's. It's difficult, but it's it's worth it. And it's important that we, that people do it and people enforce it on their teams. And again, this is one way that if you're, if you're a tech leader, in your organization or on your team. These state machines can be one of the ways that you can help spread that knowledge and enforce that behavior. You know, one of the things that I wanted to spin off on, which is funny because you mentioned reach UI uses state machines.

And I was just corrected about this on Twitter recently.

Play from 26:00

I had mistakenly believed that they were using XState because I, I could have sworn that what they had shared on Twitter was an XState visualization. And, you know, and it might well have been. But they were using kind of their own implementation, a compliant implementation of the state machines. And I think that was something that was worth calling out here. You've mentioned it sort of in passing a couple times, but X8 is not a re-imagining of state machines. It's not a totally unique standard. It's built on the shoulders of a lot of, academia, a lot of papers. And so even if you're afraid of committing to any one library. I mean, what's great about using this is that it is built on a standard. So I don't know if you wanted to speak to that at all, right? Yeah, the important thing is that these ideas carry over. X8 isn't the first state machine library, and that in JavaScript, it's definitely not the last one.

There have been a few, recent ones which, you know, are actually pretty cool in their own rights. But uh. XState does follow SCXML, and it tries to adhere to it as closely as possible, by the way SCXML stands for states chart XML. It was a, a standard, a W3C. Recommendation that was published in 2015. So quite a while ago, now feels like forever ago. But so SCXML defines a standard for just everything having to do with statecharts. You know, parallel nested states, transitions invoke. And so, if you actually read that spec, you will unintentionally learn. XD just because so many of the things are the same, and that's because XD tries to stay compatible with SCXML. And that's actually on purpose. First of all, like I said, lazy developer, I don't want to have to think of these new things. I would rather like, Oh, there's a spec that tells me exactly what to do.

Perfect, I will just follow it, uh. Secondly, there's implementations of SCXML in other languages too, such as Java, Python, C plus. I believe, you know, since this is a standard, they could just implement it as is. And so what that means is that XState could theoretically create state machines. Have it converted to SCXML and had that be interpreted by other languages? So not only is it framework agnostic, it's language agnostic as well. And third, just like you said, the ideas carry over to whatever steam machine language you're using, like, you can't exactly all right. So, Mob X is a really great library, but you can't exactly carry over whatever you're doing in MobX to something like Vue X, despite the similarity in names like, it's just two completely different worlds, but anything you do in XState. If there's a another state machine library, you could just basically copy paste the same things over, you know, it's the same ideas.

And so that's why, yeah, it's completely natural that both Radix and reach UI have their own state machine implementations. Partly for size reasons, partly because, you know, they don't want all the features that are in essay, which is totally understandable, but the ideas are exactly the same. And, in fact, with reach UI, I think you could even copy and paste the exact same objects. Put it in the exit visualizer and it's going to visualize the same machine. Despite it not being written in the next state. And so that's, that's on purpose, great. So, you know, we're here at the beginning of 2021, it's always a time for sort of looking forward for, planning for. For resolutions, I mean, you mentioned statechart I O, and some of the things that you have planned. If not for this year, for the future. Is there anything else that you wanted to kind of get people excited about?

Either new scholarship, you've read about state machines and statecharts, or just things that you have planned for XState and the XState community? Ah, there's so many things I have planned for XState and so little time. So, uh. One of the big things like we talked about is just having a repository of machines where people can freely use and share with other people. Basically like a library, right, you know, just a shared collective of state machine knowledge. Also, I, I want to take the inspector to the next level. So something that I've been working on for a few months and, still working on. Hopefully releasing a, you know, Alpha soon is a statechart creator, which allows you to visually create these date charts instead of having to code them up. And, it will generate code, so if you want to physically add more code to it, then you totally can. It works in both directions, but I think that's a natural next step for, you know, being able to visually create your statecharts.

And then let's see more testing tools. I'm also working on the next state version five. And by me, I mean, like me, and, a couple other, contributors on the Etsy project, thankfully, I do have some help there. Yeah, I, I just have a ton of ideas. Things I've shared at React-a-Thon, like, actually a lot of things that I've shared in previous talks. Like, well, reactive Conf, React Thon, some other conferences are all just like future ideas that I want to implement one day. So one of the things that I shared that reacted on was the idea of taking an application that uses XState. And being able to, generate not only documentation for, like, just everything that you could do in the app, but also, generating these flows in a visual way. So take a shopping cart app, for example. If he wants to show the user, here's how you get, here's how you basically check. Out and get to the checkout page.

It will render the app at each one of those states and show you exactly how to get there without any manual effort from the developer. So it's all auto generated. And yeah, I, I, I share. I remember this talk, I don't know if it's the exact talk you're talking about. I remember watching one of your talks about the, potential for automatic code, an automatic test generation, and that blew my mind. It's just the possibilities of that. To feed a state machine into something, into a tool and have it say, Okay, let me manipulate your, you know, your tool. You know, this is how I send this signal, this is how I send this signal. Now, let me walk through all the states of the system, and including the impossible ones. Make sure the system's responding correctly. Very cool potential there. For correctness, you know, in an environment where we've often been jokingly said that, you know, software engineering is the least engineering of the discipline.

Engineering disciplines, any, you know, ways to get more correctness and more provability to our systems, you know, is kind of a cool, benefit, for sure, right? Yeah, I see basically bringing engineering into software engineering in a way I love it. So, you know, in conclusion, sort of the last question that I had for you and about I guess I'm a bit more meta level is, you know, I was reading, catching up on your, on your Twitter and in advance of this, and.

Play from 36:00

And I saw that. One of your resolutions for this year was to do, even more work. Affecting sort of users and customers, and not necessarily just in developer experience. Which led me to sort of think, you know, sort of an interesting thought. I just saw another sort of thread. In response to state of JavaScript by Ken C. Dodds, who was kind of him. And Ryan Flores are sort of remarking, like, Hey, Ken. Did you ever think that you were just going to become the testing guy? Like of all the things that you could have been known for, like, did you think you would be the testing guy? So I guess my kind of question is. Is did you think you were going to become the state machine guy? Sort of, what? What do you think about that? Sort of? I'm sure you're appreciative, but like, how you know, just is that crazy to you? Or like, where do you see that going in the future?

It is, it is crazy because, from my, from my very first, you know, big boy development job like I. I've been thinking of, you know, just using state machines and learning more about them. And I thought that it would be just a really niche interest. In fact, one of my first forays into steam machines was just reading this introduction to computation and finite automata, or like, just this really, really math heavy textbook on, you know, just learning about the stuff. And so I was like, you know, basically, no one is going to read this for fun. So, I, I. I thought like that would have been a niche topic and I would be more like just the person advocating animations, which, to be fair, like I, I still try to do that. And, in fact, we have a show called Keyframers, every week, and I think we're actually doing a stream today. But, basically, we try to merge state machines and animations together and just show developers how you could use state machines to make animations.

More reasonable, more, readable and easier to code. So, yeah, animations are also a huge one. My interests and I, I feel like that's what I was known for before state machines.

Play from 43:00

So, and somewhere back there, there was music involved, you know, oh yeah, that's, that's a piano in my name, so that's great. So, yeah, so that's pretty much it for today. I mean, I think I will end with one more thing. As we love to reach out to people, especially people that are aspiring software developers, and just say that, you know, if anything that you heard today inspired you? And you feel like you want to bring it to a local meetup or give a talk, or write a blog on it? I can personally vouch for the fact that David and the rest of the XState community is one of the most supportive on tracking. When people are. Doing these things, supporting them, maybe even showing up in the comments section sometimes if it's an online event, it's a really cool, really supportive community. So if you're looking for a place to sort of jump in and just sort of meet people and kind of get involved, this is definitely one of them that you should be looking at.

So, I don't know, David, if you had anything specific that you wanted to point them to. If people, were, you know, were just looking to kind of get into sort of the community generally, yeah, well, we do have a community on Spectrum.Chat. Slash statecharts. Sort of moving away from that, though, seeing where, where we're gonna end up next. GitHub has discussions now, so you could go to XState David KPM discussions and just, freely talking there. We also have a Getter chat at, I think it's statecharts, I know the exact URL. And, pretty soon we're going to be getting a discord. Because I feel like that's also the natural next step. So yeah, that is the next thing. All right. Well, great, that's it for today. Thank you everyone for listening to this modern web podcast on statecharts and state machines in XState. And thank you, of course, to our guest David.

As always, we say the conversation does not stop here. So if you want to reach out and talk about any things that you heard today, feel free to find David on Twitter at @DavidKPiano. That's d-a-v-I-d-k-p-I-a-n-o, you can find me online at Robocell, so that's r-o-b-o-c-e-l-l. As for the podcast, you can find us online at moderndotweb..com or on Twitter at modern.web. As always, thank you as well to our sponsor Syncfusion and we'll see you all next time. Thank you bye.

Play from 45:00