Build Better Apps with State Machines

Hello everyone and welcome to another episode of learn with Jason. Today on the show, we're bringing back everybody's favorite state machine master David Corsi. David, thank you so much for showing up today, thank you for having me. Great to have you here again. I'm, I'm super pumped. Because, I was telling you before the show. We did a show on state machines a while back. Quite a while back, actually. It was like, over a year ago, I think, and yeah. Since then, I have become more and more of a fan of state machines. I've been finding more and more ways to use them. I think they are an extremely powerful concept. I've, I've fully bought in, right? Like, I think that it is a great solution. And since you and I talked, it sounds like there are even more tools and things that we can be using. That I don't even know about yet, so I'm so, so excited to dig into that today.

Okay, but before we talk about that, let's talk about you a little bit. So, for those of us who are not familiar with your work, do you wanna give us a little background on yourself? Yeah, sure. So, I'm a web developer, just like many of you here. I'm assuming I don't know what kind of audience Jason gets, I'm assuming it's a nice, big, wide variety. But anyway, I work at Microsoft, I've been at Microsoft for about four years now and I, I sort of touch everything. So not just web development, but just, you know, infrastructure, devops, just all sorts of different things. And yeah. My passions are animations and state machines, and, you know, innovative user interfaces and stuff like that. So, yeah, that's basically me in a nutshell. Oh, also, I play piano. My last name is not piano, I played the piano, so that's what, that, that's what that's about. I, I went to college for piano, so that's why that sort of stuck.

Yeah, and you have a, you have your own stream, right? With, with Shashaw, yeah, Steven Shaw. So we, do the key framers. And we actually don't do it on Twitch, we do it on YouTube. And, actually, we're almost at 10 000. Subscribers, so please check this out. Yeah, yeah, yeah. I think for our 10K episode, we're going to do like a code in the dark sort of fun challenge. That's hype thing, so super cool. Yeah, here's a here's a link to that. It's like, I love, keyframers, it's one of my favorite, one of my favorite formats I've seen. And one of the things that I especially love is when you set up where, like, you just kind of start riffing on the piano and then you build a audio visualizer. And like, I've seen a couple of these and it's such a fun format and like such a cool way to see things happen.

I love that idea of kind of like parallel creation. Yeah, it's. It's really, really fun. But anyways, if you haven't seen the keyframers, definitely go check it out.

Play from 0:00

It's a really, really fun format, a really fun show. Okay. So before we go too deep into this, I'd love to just address the broader scope of. Or maybe we should start with a definition, what is a state machine? So a state machine? Don't go to Wikipedia because you're gonna get a whole bunch of mathematical jargon in your face and it's just gonna be really confusing. But a I. I guess the best way to describe a finite state machine is a description of the behavior of a system and how it changes over time. So, for example, you and I are, well, finite state machines, or at least conceptually, so. You could be asleep or you could be awake, right? You can't be both asleep and awake at the same time. So that's one of the core principles of a finite state machine, you could only be in one finite state at the time, and, like I said, finite state machines describe behaviors. So you might React differently to something if you're asleep, or, you know, not React at all because you're asleep, than if you were to be awake.

So your behavior, when you're asleep versus when you're awake is different. And so, finite state machines just allow you to encode that in a very deterministic and visual way. You know, you have boxes and arrows, and each box represents a finite state or behavior. You could be in. And an arrow or a transition tells you how you could go from one behavior to another. And we see this all the time in apps. And like you said, the more you play around with it, the more you just start seeing these state machines everywhere, really. But in this, I think like, a good example that you've given to show why this is so powerful is that if we don't write state machines, we're still writing state machines. They're just not very good ones because we end up having an is loading and an is error and is active states.

And all of those are true and false states, and theoretically, none of them can be true at the same time. But if we forget to write one of those if-else statements, then we can end up in a situation where they are true at the same time. And so that's something that state machines are kind of built to prevent, right? Like it's. It's instead of relying on you to be a good programmer, it's relying on the architecture of the thing to automate that, right, exactly. And so you brought up a really good point with Boolean variables like, obviously, you know, you could be a very smart developer and say, well, if it's loading, then obviously it can't be loading and not loading at the same time. So I'll just split the bits and make sure that the boolean variables don't conflict with each other. But the problem is, you are writing these gnarly if statements with like, if this and not this, or not this and this.

And it just gets really confusing when all that could be described with just one enumerated value or finite state. Absolutely, yeah, I think, and we'll show how this works to, I think, make it a little more obvious when we get into the code. But that was the light bulb moment for me was when I realized that. Like, I think, when I first looked at state machines, I was like, this is a lot of code, right? And and I think that, yeah, you start to look at it and you're like, man, I'm I'm writing a pretty decent chunk of code here to do something. And you always see the basic example like. A stop light or something, and when you look at that, you're like, well, I don't need this much code for a stoplight, but that's not what real code looks like. Real code isn't a stop light, real code is really complex.

And what I've noticed is that the size of my state machines does not grow at the same rate. Of all of the like, bespoke logic that I end up writing to manage the if else statements. It actually grows more slowly, so it starts out as more code, but it stays more tractable and understandable than this kind of. Oh, I'm going to write this little if statement here, I'm going to do this switch statement over here. And you know, all these different things that we do to manage state, that gets spread out through your whole code base, right? And honestly, I think that's why people are actually afraid of state machines is because they start with the simple examples. And they're like, first of all, it's a huge learning curve. Like you have to learn about states and transitions and events, and just all the different parts of state machines and statecharts.

And also, like, like you said, state machines can look like a lot of code for simple examples, but it's because state machines don't remove complexity. Instead, they bring it to the forefronts, they expose it and make it explicit so that you know all of the edge cases that could possibly happen. In an app, it's like, right there in front of you, instead of being hidden in some abstraction. Or even worse. Like, just having you assume that the happy path is going to happen all the time, which, you know, that's pretty optimistic. And I actually tweeted about that today, I saw that tweet today. I was thinking, I was thinking that was a good, a good one to bring up. Actually, as we were, as we were making this transition. Yeah, but yeah, actually, you know what, why don't we do that? Let's let's switch over into pair programming and we can start showing some of this stuff in examples. Instead of, instead of talking in the abstract, and while we're doing that, make sure you head over to, to Twitter and follow David.

It is a. Great account to follow, full of really good information. And here is the, let's see where is this here? This one there it is. Here's here's a really good tweet that kind of talks about like, this is a very good point. You you write code and you think that it's going to work like this. But there are all these error cases and things that can go wrong. And if we don't handle those, which? I mean, you, you can watch me on the show when I'm like, Ah, this will never happen. And it's absolutely just ignoring an error case, right? So that, I think, is one of these major pitfalls that we have. Where we just get it in our heads that we're like, well, this is simple code, but it's it's not simple code. It's simple code, right until something goes wrong, and then it's extremely complex code, exactly.

But yeah, so, so. Keep in mind, if you are interested, we have live captioning being done on the homepage of learnwithjason.dev. You can head over there and follow along live. With everything that we're saying, that's being done by Rachel at white, co-captioning. Thank you so much Rachel for being here today, and the captioning is made possible by our sponsors. We've got Netlify, Fauna, Auth0 and Hasura all kicking in to make this show more accessible to more people. All of these are linkable, so you can head down to that homepage and just click on one of these to check out these sponsors. Make sure you go and do that. And the library today that's in question is XState, so we're going to be working here. And while I've got it up, make sure you go and check out the keyframers. This is a very fun, it's a very fun site, there's also very fun.

Merch I'm, I'm a big fan of a lot of these, there's some, there's some good stuff. So does. Does Steven do the art? Yeah, yeah, he does. And actually, not that I'm saying, don't buy the merch. But, in a future episode, we're just gonna be doing some giveaways soon. Okay, there's your incentive. Y'all go watch keyframers, get free stuff and these are, these are really cool. I, I own a. Couple of these I specifically, I love this one, it's one of my favorites. But, yeah, go check that out, it's gonna be a lot of fun, okay? So, David, if we are looking to get started here, what should I do if I just want to kind of set something up? Do I? Good question? So go ahead and go to the GitHub just because I have some, or actually could go the docs, doesn't matter which one like to scroll down. So I have a bunch of templates because, you know, people could be using X data in any way.

And in fact, I created XState, so that is not framework specific. You could use it with. React views fell to Angular. Whatever, and so, um. One of the simplest ways to get started is to use, the XState Reacts template. Just because you also have those, visual components there. And if you click that, you could fork that. And sometimes the word template throws people off. Because, you know, it sounds like a bunch of setup, but there's actually really not much setup in here. It's just a very simple app. It's using XState to create the machine, and XState reacts to use the machine, which, it is a used machine hook, and that's it's basically a fancy useReducer. Like, there's nothing really that special about it. Yeah, yeah, okay. So I'm going to set this up as Xdatelearnwithjason.

Play from 3:00

We'll give it a name good. Then I'm going to, can I just share this as an everyone can view? Yeah, there we go, okay, so you all can just check this out. I don't think this does. Live share, though, does it like this won't update it, it has its own version of live share. Which I think you've done in previous episodes, right? The whole collaborative, or you could just code the whole thing, yeah, how does? How do you do the collaborative thing? On here? I haven't, I don't think I've tried. To the left, all the way to the left, the two little heads right under the Oh, here we go. Okay, okay. So yeah, we can, we can do this. Classroom mode, that seems like what we need. Why don't we do this setup here? So if you all want? To follow along, you can see this go, and hopefully that'll be, that'll be manageable for us.

But so let's check this out. So we've got in here a machine, and is it doing anything? So this is a toggle, right? That seems it seems like something that is pretty, pretty common to make. Yeah, it's also one of those like, potentially overkill things, the. The purpose of this is just to demonstrate two parts of the machine, which is going between states inactive and active. And also assigning to context in context, you could think of as your infinite state, like your extended state. So okay, yeah, so this and context like this is another thing that I think is cool about state machines. Is that a lot of times, like when I'm thinking about, oh, I might need Redux for this, or I might need whatever for this? If we're, if we're keeping it to a component or to a particular piece of an interface, and nothing needs to escape that interface. Like in this case, this little section.

Here, we're tracking the state of the button and how many times it's been clicked. We in this interface, for sure, but like potentially in other ones, this never needs to escape this little suite of components, right? So why would we need to track this in some global state, why do we need this to be globally accessible? We can, we can keep it contained and make this very portable, very self-contained, and therefore a little easier to debug. And reason about, which I think is a pretty powerful concept, right? Yeah, XState doesn't care whether you're using it locally or component-wide. And it's also a little bit of a departure from Redux, because Redux is one single global store, whereas XState gets more into what's known as the actor model. So you could think of that as a store that could spawn other stores, and those stores could communicate with each other. But yeah, that's getting pretty into the advanced XState sort of stuff.

But, you know, just letting you know that you could use this either locally or globally, yeah, doesn't matter. Yeah, okay. So if we want to kind of play with this, it looks like we've got three pieces here, so I've got a machine and. This is, this is coming out of XState. This has context and states. We've got two states, active and inactive. And then we've got the on is an action that we can perform and what state it goes to, right? And this is, this is, I think, what makes this really powerful. Because basically what you're saying here in this code is that if I'm inactive, the only thing you can do is toggle, and the only place you can go is active. So we're being super explicit about what's possible from the inactive state. Yeah, yeah, that to me feels like a very, what you said about, like, how you're. You're not just assuming that things are going to work, you're being very explicit about.

You know, these are all the edge cases, these are all the workflows, these are all the active, the possible states, and you're writing it down. So then down here we have the useMachine hook and that comes out of X8 React and that gives us current and send. Okay, and current is the current state. Yeah, is okay is the current state. So we've got a dot matches where we can check if it's the active state or the inactive state. And then we've got send, which allows us to send the toggle action. And that's really all that the that X data is doing here. Like we, we're checking if what state we're in to determine what the UI looks like. We've got a function that sends an action and everything else is just React. Yeah, so, you know, people who have used reducer before, or even Redux, this will immediately feel familiar. Basically, you could think of this as a reducer with rules, right?

You have, different things. That could happen depending on the event, but it's not just based on the event, it's also based on the states, and then you have your way to send events. Redux calls this dispatch, and, by extension, since Dan Abramov works at Facebook, it's called dispatch, with useReducer, too. But I like the word send. Send is closer to the actor model, so sure, that's why I sent this using setup dispatch, but semantics doesn't matter. But so this, and here's what's really cool about this, right? So if I, if I want to make, like another component. And we want to say, like, let's say we want to have a paragraph that says, if this is active, we're going to say something like, we'll say, hi, you've activated this paragraph. So if we want to make this visible, we could, we could have like an is active state or anything like that.

But because we've got the current here and we know that we're using the current matches, then we can just do like, active, active. And yeah, right, and there we go. Now we've got, yep. So, that there's actually an interesting point here. A lot of people think that I'm completely against, like, is loading, you know, is active, is inactive. All those boolean variables, and I'm really not. But I just think that those should not be the source of your states. Those should be derived from something like a state machine. So that's why we have on line 26 const. Active equals current dot matches active. So now that boolean active variable is not like the source of truth, it's just reading from the source of truth. So yeah, and the source of truth is this state, which we can see here. Includes this, you know? We've got a value of what the current state is, so when I click it, now the state has updated and we've got a value of active and there's a bunch of extra information.

But we also have this context, which is super powerful, so, you know, we've got, like, our count here, just comes out of the current context. This is like to me. This is just something that it makes sense in my brain because I like to think through what actually happens in software. And one of the things that I think is really powerful about XState that I've never seen in anything else, is the fact that you can visually think through how state machines work. So, you know, instead of drawing a software diagram and then having to figure out, like, all right? So how does this part of the code map to this part of the diagram?

Play from 12:00

With XState you can, you can make the diagram and it is the code. And that part, I think is really, really exciting, um. Oh, why is my slack on? Get out of here, go away, all right. So I want to take this to the next level. Absolutely, I do all right. I'm just gonna straight up post this in the in the Twitch chat. But, this is the same template. Except now we have, the XState inspect package and that's gonna pop something up. So if you don't see anything, you might need to. Just allow pop-ups on code Sandbox. Here's my preferences. We're going to allow pop-ups. Okay, do I need to reload this to get it to work? Probably, yeah, okay, so this one, that one didn't work, but this one does. I think that must have been, yeah, actually. I might have sent the normal React or the normal, this thing, which doesn't have the React stuff, the React.

One might be better, so let me actually send that one over. But yeah, there's there's a lot of things going on here. And basically, whatever machine you have there is visualized with this inspector. But I just sent over the UM. Or in the Twitch chat, I put the XD Reactviz template. Okay, so it's gonna be the same thing that you saw before, but visualized. Yeah, so okay. So if I close this down and we take a look, we've got inspect coming out of XState inspect, yes, that sends over to statecharts..io inspect. And so this is something that like. I don't need to configure this or set up an account or anything, it's just going to work if I send to statecharts inspect. Yeah, yeah, it is. And so stitch art style, Io slash. Inspect, that's just a React app running and listening for window events. So got it, just the sort of a 30 000 foot view of how this works. When you're, or so what, when you call inspect, it's going to attach something to the window that basically is a place to, store machines that are interpreted.

And so when you run machines in, with dev tools, true, which I think if you scroll down, you could see that. We have the DevTools true setting in the used machine hook. That's going to attach that service to the global window object. And. The inspector is going to listen for that and send events back and forth between that inspector window. And and your running application. Cool, okay, this is really, really cool. Okay, so let me, I just closed one of these. I didn't mean to do that. Okay, so if I have this one and I take this one out, are these like, synced? Yeah, they're synced. I think I need to maybe pop this twice, I might need to reload the first window and hopefully that works. Oh, it might be a size thing. Ah, yeah, so you know, okay, no, no worries. Okay. So if I make this one a little bit bigger, it should work.

Probably. Yeah, it works. So I'm gonna close this and then we can take this one and then this is. This is reactive, right? So if I click this, does it, it will. Oh, I think I broke it. Okay, we're gonna try this one more time. I'm gonna reload and then I'm gonna pull this out, make this bigger so that we can see it. And then I'm going to click this button, look at that, okay? And now this works the other way too. Oh my god, it does so. It's a bi-directional thing.

Play from 20:00

Yeah, oh, that's so cool, so th this, this is incredibly cool, right? Because what? What we were talking about this being visual, this, this is the visual component of this. Because check this out now. If I want to add another state, I can come in here and I can say, I don't know. We'll call it unused for now. What did I do? Are you wait? Why are you helping? Stop helping? And then I can say, like, on, and really, it just drops that unused state in there immediately. That's that's incredible that we can do that, right. Because now I can, I can sort of map this out as I go and say, like, if I, if I was going to do something where I needed to be able to kind of think through my states. Okay, so I'm going to have an open state and then I'm going to have a closed state. And then I'm going to have a like, I don't know, like, a closing state and the opening state so that I can.

Do animations all of that? I can just start thinking through these and I get all these states out here, and then I can start thinking about how they move and connect. Exactly, yeah, that's so cool, that's, that's incredibly cool. Do you want to do that? Actually? Do you want to do, like, a little, a little, how you would animate with the state machine thing? Yeah, yeah, sure, we could do that. You might need to give me access to the I think it could just make me an editor instead of a viewer. Okay, yeah, I think I can do that. Sandbox. That's exactly how it works this back over here, so that we can, make this bigger again. And then I think what I can do is I'm gonna have to fork this one, I think. And then we've got a new live session, oops, so we can drop that in there. And then once I should, I should be in right now, all right. So now you're an editor and anybody who wants to come in, come in.

And oh, no, what did I? What button did I push? Am I back? I'm back? No, I'm not. Oh my god, what have I done? Okay, what if I go to this? Okay, I'm back in, am I myself? I am okay, and so then I can, I can close these down and we can see again. So we've got our state machine. Okay, and I think I could type, yep, I could type, all right, perfect.

Play from 24:00

So we'll have to see if it's. I think it's going to open a new window every time we reload, oh gosh, I think it's supposed to reload the same window, but it might not. That, honestly, I'm using, Firefox, so it might be that it's, it's rebelling. If I need to, I can open Chrome and see Chrome if it wants to argue, yeah, people in the chat are mentioning like, yeah. It is working with window events and that's basically the mechanism that's working by, and there's actually talks on what those window events are. In fact, like, right now it's pointing to that statecharts, dot Io, slash and specs. But there's really nothing stopping you from making your own local, visualizer. It's just a lot of developers. Are too lazy to do all that, which, that's fair. It takes hours and hours and hours of work to, do this. But yeah, okay, I'm I'm getting signed into Chrome here so that I can see this. And and hopefully it'll do what we want.

Which is not open a new window. So yeah, people in the chat. You could definitely just point this to local host and receive events that way. You just have to visualize it yourself for now, which is actually not. It's not too hard to, do this. The hardest part, by far, is the arrows, like just connecting all the arrows together, and that's something I've been working on for months. It's not an easy problem to solve. So, yeah, okay, so here's state machine. I think I have to refresh it because I had to allow the pop-up. There's our pop-up, there's our state machine. Okay, so now I think it should cooperate as we as we work through this. So we've got, we've got our states here, and we are, uh. We know that we want to have an open, closed, closing and opening, and the general idea is that we want to be able to have something that maybe it's a an expanding box or something.

So if you, if you click the button, it's going to open a div and show you something. And if it's, if you toggle it back close, then it will, it'll animate shut. Yeah, so, I, I went ahead and made the initial state closed. You know, we can just assume, that's closed, and we can do your, see that happening here. It's so cool, your paragraph thing here. Oh man, this doesn't do auto complete, I have to type in lorem ipsum from [Laughter]. Dolor sits Ahmed Khan, Sec. I, I have no, I, that's all I memorized from Lauren Ipsum, but yeah, you got four words further than I did. Yeah, so, yeah, we could, you know, do something like make this paragraph or whatever appear and disappear. And the meeting. And now just like a really simple example. Yeah, yeah, exactly for that, all right. So, let's see in the close date we could think about, how we wanted to open, and, this is.

Something that I enjoy about state machines since Daytarts2 is I don't have to think about adding event handlers or doing on click or whatever I could just think of. In an abstract sense, I want just some sort of trigger to open and close this, so I could just say on open, and you know, I, I could define that later, I don't. It doesn't matter where that event comes from. So we could say opening, and opening. I could just say, we can see it happening too. We could say after like, a second, it should be in the open states. And you know, I think that's a good starting point right there. So, yeah, let's, okay, I'll let this say, and I think, Oh, you're down here, yeah, yeah. And so, yeah. I'm trying to think about how we actually want to, well, and before we even like, write the code, we can actually try this in the in statecharts, right?

Oh yeah, yeah, so if I, if I come in here and I see we've got closed. And then when we hit open, it takes us to opening, and then it waits a second and then it moves to open. So there we go. We know that our state is now predictable, right? We don't have a way to get from open to close, but we know how to get from close to open, and that's really exciting. Yeah, and so I'm just going to copy and paste some logic over here. So that we could also do the closing thing, closed, and we could also say, like, if it is closing, and we decide, you know what, never mind, I don't want to actually close it. Sort of like, I don't know. Stepping in front of that little laser beam in your garage, oh yeah, when the garage door is closing, just to make sure it doesn't kill you or anything.

You know, oh, that was a weird analogy. [Laughter]. But yeah, you're right. We can't really go from, oh wait, open, aha, on close go to closing. There we go. And so now we should have a full loop. So we're on closed, we open, it goes to opening, and then it goes back to open now if we close it. It goes to closing and then it ends up back at close, so then if we open it, but then I close, it immediately goes back to closing. Ah, beautiful, look at it, go, that is, that is such a nice like. We just know that's gonna work and then I can open it again as we start. Yep, perfect, yeah. One other cool thing, which is sort of a I. I didn't really put in the docs or anything, but, sometimes you want to have sort of documentation for what your states really mean. So I want to say open, let's just say meta description, and then you could put any sort of mark down in here.

So I'm just going to say, the box or whatever you're trying to animate is fully open at this point. Okay, I've never seen this. Yeah. So now if you go in here, it will show that description in the state machine. And so it's like, comments on steroids. Wow, look at that, go, okay, that is, that is legit, that's super cool. I see that the chat is having a good time with my floating dumpster fire. [Laughter]. At least they're not putting it on your face, I guess, that's okay. And so this, this, this looks like one thing I'm noticing is that this is a little bit jumbly. And I think that's because of the order that I initially typed these states out in, right? So if we reordered this to be like closed and then I take opening and I move opening up here, and then I took open and moved that here.

That, yeah, we. That immediately reorders the state. So that it's a little bit easier to read, which is nice. But yeah, this is, I mean, this is like, I just I chat. I hope I hope that this is really exciting for you. Because what I think is so cool about this is that we're taking something that is kind of hard to separate. Which is the man. I said, put it on your face, and they immediately put it on your face. Cool, chat, cool. What did I tell you about harassing the guests? You're not allowed to do that. But so the what the part that I. Find really exciting about this is that what we're doing is we're basically being able to say. I don't have to think about the animation yet, I don't have to think about the the like UI yet, I can just think about what needs to be true. And then, based on that, we're able to, like, very quickly, write that out.

We can map that out, how it goes from one place to another, and all the certainty that we get from that. And then we get to switch to the next context, which is now that we know that we've got an opening state that lasts for a second, we can animate for one second. And I'm drowning in boobs. Shruti Hello, how are you? [Music] Wow, that is a lot. Yeah, yeah, that's this is, this is how it is. Does it ever fill the screen completely? It definitely does. Usually when Cassidy shows up is when, when enough people rally to really clear the screen. But so okay. So now that we've got this, then what we can do is we can look at it and we can say all right. We know that if we've got our, our paragraph tags here that we want to have, let's see. So we would need, like, a style, how do you do classes in React when you don't have a library installed for that?

We can't just drop a style tag.

Play from 27:00

I'm going to show you something different, okay, something that I like to do because, classes get messy. It's the first thing, what that we reach for, just because it's so simple to just do dot whatever, like dot loading, dots, loaded dot error. Just I have a different plan. So, we're going to use data attributes and I'm going to say data state, and then I'm just going to go ahead and put the current value. Because since this is a flat state machine right now, we know that's going to be a string. And so now we could just jump into the CSS and dial that however you want. So, well, let's actually give it a class name, just a single one, equals thing. I'm so careful with naming. And I'll just I'm gonna go into styles..CSS, or, yeah, that is CSS. So we could say dot thing, maybe give it some padding, a border, two pixels solid.

Papaya whip. Actually, that's a terrible color, but because you can't even see that with a tomato, and in honor of our good friend, to me though, yeah, John O'Tander, he loves tomato. All right, awesome, um. And so this thing can be in a couple of states, so we could say data states equals. Opening, oh, I like this. So we could say while it's opening, we have opacity 0.5, and then when it's fully open, we could say opacity 1. And, backgrounds, let's just make it red green. Sure, I don't know, five. This is actually something new I discovered, like, if you have four digits, this one stands for the alpha. Yeah, I don't know how wide the browser support on that is, but it's pretty useful. Instead of just doing the whole RGBA mess. So we'll just call that open and let's also give it a transition to see things transition smoothly. We'll just do that.

Okay, simple, and so I think it should. Oh yeah. Also, we need something to actually trigger those states. So we have open, we have close, and so we could just make a couple buttons. I wonder if Emmett works here? No, it doesn't, huh? Shame, uh. Button, we could say open, and then we could say on, click, equals, send, open, and so that should just work. I'm gonna get rid of the other buttons too. And and so chat like I, I, I just. It blows my mind. Like, first of all, this, the data state is already just like a very good idea. But I think the power of what just happened here, where we've basically been able to say, like, I want to send the open event. And we know that when that happens, it's going to step through these things without us having to do. Oh boy, keep helping, I guess.

Look at that, but you see what just happened. So we hit that, that open button and it goes through those transitions. It's it's still popping me open into that window, so it, but it's there, right? So we've got our we've got our styles going, we've got the opening and closing, um. I'm just in a battle at this point. Okay, I'm gonna move this to the side for a second so that it stops all right. Yeah, you. You could also just disable the inspector just comments it out or something like that might be easy. So we have, so looking at this right? We've got, so we've got the thing we've got the opening and closing. We're going to go to, half opacity. When it's open, it goes to full opacity and has a background, and when it is closed, it has zero opacity. And I wonder, actually, if we set like the background here to be, zero opacity, I think we'll even get a transition in the background.

I think possibly I'm playing around with the button right now. The the default styling of a button always makes me want to just immediately change it. Yeah, look at that go. So now we've got this really nice kind of transition. It fades in and out. And if we look at our statechart at the same time that we that we click this button. So if I pop this over and I'm going to close this down and then can you come over here? Yes, all right, so check this out. So now when I've got this and we'll make this a little bit smaller so we can see. I hit open close, I think it dropped my, oh it, oops, I'm looking at the wrong state machine is why that's not working, so check this out. So now when I do this, I open, we see it move through, we close and it moves back. This is just like.

This is such a next level experience for developing and debugging, where I can just very quickly say, Okay, well, what happens when it closes, though? And now I don't have to build this so I can just open it to get to the point that I want to be.

Play from 37:00

And like, only build that part of my UI so I don't have to build like all these transitional pieces to test something, I can just define the state machine. Use this to jump to the state that I need to be in. And then work on that section until I'm happy with it and then kind of transition back. Like that, that, to me, is, is where this really becomes kind of a game changer. Because you just can't do this with other state management things without a ton of custom dev, right? And that's why, like, there's all that you know, structure. A lot of people say that XState is really useful for organizing your logic. And like a lot of state managers like that, obviously they try to focus on ease of use, like, oh yeah, just mutate or not mute, but update state whenever you want. And yes, that makes things easier, but you know that's not necessarily the goal of X data.

X data is meant to make things more organized and predictable. And let you identify the edge cases before it bites you in the butt later. Absolutely, yeah. There's a question about using this for Vue, and XState is totally kind of agnostic, right? You can use it with whatever it is. In fact, just like X8 reacts, there is an XDateView package, and in fact, we recently updated both the XD React and the XDateView package. To include a couple of new hooks. So, yeah, since the last time we talked, a lot has changed. Well, I don't want to say changed, but a lot has been added to XState. So if you go into the docs or GitHub, yeah, there is a should be a view template there. In fact, when I first, when I first announced the XState inspector, the example I gave was in view. So, you know, you could use the inspector in absolutely any framework and XD as well, for that matter.

Yeah, the and this is really exciting stuff because it's, you know, and the other part that's exciting about this. Just kind of looking at it is check this out. When we, when we look at how this works, this is exactly the same, you know, we're not so. This also means that instead of having Redux in one app and a home rolled solution for your vanilla JavaScript app and something in View X review, now you can have. Your state is managed as state machines. They look the same in every app. It starts to create this, this kind of universal language between the developers on the teams, so that. Is such a like? As someone who has worked on large teams, one of the hardest things to do is manage team workflows, especially when everybody wants to build in. You know the framework that they prefer, or they've got different, different business requirements.

That mean that React is better for this. Or they want to use JQuery for that one. Because it's not very much interactivity and they don't want to add a lot of page weight, so on and so forth. But if we know that, we can rely on a state machine to be a state machine, to be a state machine. No matter what framework we're working with, no matter how we're deploying it, that gives us a lot of ability to make our skill set cross-team and cross-functional. There's a lot of training that works no matter where we go, no matter what stack you're using. Yeah, absolutely, and that's what I love about it, too. Is that state machines and statecharts are really a universal concept, and by universal, I mean, the computer that you're typing on right now would not exist without state machines. Like it's all over the place in electronics, and, just basically everything. And by describing logic and state machines and statecharts, you do have that common language.

So it's not like, learn Redux or learn React hooks and do it this way. And if we change frameworks, good luck with that. Try to decipher all the code. Instead. It's you're using things that are over half a century old, and, you could just transport them from framework to framework, or even language to language. Actually, yeah, I mean, it's, it's. This is really like, it's just very exciting stuff because it. It makes me feel good about writing this kind of code because it doesn't feel like something that. Okay. We're gonna write this now and then in two years, when whatever comes after the stuff we're using now comes in, then we're gonna have to tear everything down and do a full rebuild. And this becomes legacy code. Like, the way that we write state machines hasn't really changed in a long time, and it's unlikely that it will change going forward. Never, gonna, never gonna change, unless, unless we suddenly all have quantum computers and the paradigms on which the.

Computers are built absolutely change underneath, but that's very unlikely to happen. Yeah, I mean, it's just it. It adds new, kind of a new color to the idea of building.

Play from 43:00

Like, future proof code, right? Because it's, it's future-proof, in a lot of ways, it's future-proof. Because this is, this is stuff that goes back to math and like mathematical theorems that can be proven. And have been at like, ad nausea, um. But it also goes back to this idea of like this, this really is portable and it's containable. And so, something that somebody brought up that I thought was interesting is, when you get into this, like, what we've talked about is really contained. It's a toggle button, it's one kind of interaction. But that's not the only thing the state machines work for. We can get pretty complex, right? So what happens when we have, like dependent states, or things like that? What's a what's a workflow that somebody might run into? Where they would need to have, more advanced, like dependent states set up, like nested states? I mean, yeah, you know what, Chad? If you want to clarify that question, why don't you tell me what you would, what you would like to see?

Because we've got we've got about 40 minutes left and we can definitely go and play a little bit. Yeah, I mean, in our example right now, just as we add more features to the silly open close, not that silly. It's just a very, you know, simple example. We see that, you know, we have a lot of repeated transitions, so we have on close closing for both the opening and the open states. And obviously we don't have it for closing because we're already in the closing state. So if you click close, it's not going to really do anything, and if you click close and close, that's not going to do anything either. So one enhancement we could do here is we could group the opening and open states together. And I, I won't do that now just because that's going to mess with the styles. But actually, and then it doesn't really anyway.

Yeah, so that grouping of states is one of the core features of statecharts and so. Right now, this is described as a simple state machine, but statecharts really take it to the next level and allow you to, make states hierarchical or nested. Which is what I just talked about. And because they're grouped, you could have common transitions for all of the child states within that state, and, yeah, you could also have parallel states. History. And none of this is invented by me. By the way, this is all going back to 1989, from when David Harel, who is a computer scientist, professor. He first created statecharts, all the way back then, month or two, I think. Long story short, in the original statechart paper, there was an example of a statechart for a citizen digital watch. Really old school, I think it was. Even before my time, I've never seen one of those watches, but it's one of those with like, the buttons on the side.

And you could do, you know, timers and turn the display on and off, and just all of these sort of functions. And so, in the original paper, he created a statechart that describes the functionality of that watch. Well, fast forward, 30 years later, actually, now it's 32 years later, someone took that exact same statechart and made a web version of that watch. It's Jakubowski, and it's one of the coolest examples I've seen. And yes, it does use Xtape, but this is a working citizen watch using the original statechart from 30 years ago. So if that's not future proof, I don't know what it is.

Play from 48:00

Yeah, it's actually funny. This thing handles dates where it's like, what happens if the battery drains? And Andy said, like, you know, to test that, he had to basically wait 15 minutes or something for the battery to actually the virtual battery to drain. Or something like that. You can see, I'm like, turning the light on right now, like, this is so cool, this is like, I love this stuff. And and so the state machine, wow, look at that holy crap, okay? So, and this is like, this is just a complex version of what we, what we just built, like we can see. Here's a here's a starting point. And this is what I love. About it is you kind of learn the language of this, like, here's the starting point, and then we can see how it transitions between things. And you know, we've got time and waiting, and so, let's see if we can find a button.

So the button. Yeah, we start with the light, it's off, it goes to on, we've got the batter. This is so cool, this is, this is such a cool like it just makes it. You know, this is still complicated, but what I love about it is that this is, this is complexity that we can untangle by ourselves. We don't need someone to sit down and do all the brain dumping to explain what was in their head and why they made this decision and why. This thing is weird, because it's all been written down. Yeah, yeah, it brings the complexity to the front, like I said, it doesn't remove complexity. And someone might be looking at this diagram and be like, Wow, this is a really complex watch. But imagine if you didn't have this and you just had code? Now it becomes 10 times more, you know, complicated to understand, because you have to basically map all of this out in your head.

And this provides a standardized way of doing so. And the dotted lines there represent regions, so they're parallel states. And you could just sort of look into just one of those regions and understand how that orthogonal region works on its own. For example, the light if you look at the lights, it's very simple, it goes on or off. And you could do that with all of the other ones, like the chime, the you know, display, all of those. And, as complex as this is. You could show it to someone non-technical and say, if we're in one of these boxes and an event happens, then, you know, then you could change the states. Sorry, my, my headphones were talking to me. Hopefully they're still connected. Yeah, there we go. What I think the part about this that's really exciting is the the way that statecharts are visualized is the way that we make flow charts, right?

So, like, if you were gonna make a decision tree, you are going to write up a. Flow chart. And it's going to say, this is the state and then what happens? And you can either say yes or no, or a thing happens, or a thing doesn't happen, and then you move to a new decision or state. And so we, like as humans, we're capable, no matter what our level of technical skill. We all know how decision trees work because they're a meme format, right? Like we're familiar with interpreting this kind of data. And I think that makes for a really powerful discussion tool. Because, you know, another way that I'm seeing this being valuable is if you go high level. And you take this to your design team, or you take this to your executive team and you say this is what we have to build to do.

The thing that you're asking for because of the states and things like that, and you can show it's not just this page and this page. Here all the intermediate states, here's all the transitions that have to be handled, here all the possible error states. Now you can start to show like this is what we have to plan for. And it becomes a communication tool as much as it is a programming tool, and that's something that code doesn't do, right? Yeah, and these statecharts, like you said, they're, they're a design tool, but they're also a formal spec.

Play from 52:00

It's, it's known as a visual formalism. And that's because not only do you have that visual artifact of the states machine diagram, but you also have this generated from code as well. So it's always going to be one-to-one with the code. I think me and many other developers sort of fear writing documentation and making diagrams. Because we could make them as beautiful and well-designed and documented with all the right intentions and the most details that we possibly could. But once the code changes, what happens, right? All of those designs and documentation go out of date. They're basically useless, right? And they're just going to frustrate developers more because they expect things to work one way. Things changed and now they're, you know, out of date. And even if you version docs, it's like, okay, you still have to write the latest version of the docs in order to, you know? Map things together.

So that's why one of my biggest goals is to, just create more tooling so that you could write code that not only lets you organize and express even the most complex logic in your apps, but is able to generate these diagrams, generate documentation, even generate tests. Just do a whole lot of, things where you shouldn't have to manually do a lot of the things that we're doing today, like writing documentation, generating tests, etc. And so that's honestly why I'm so passionate about statecharts. Not because I'm someone who just likes looking at boxes and arrows, but more because I'm just really lazy. And this makes my job a lot easier. If I could just have the computer do most of the things that I do manually. Yeah, I feel like this is another, this is similar to like. What I think makes something like GraphQL. Exciting is that you're you're taking the how you communicate and explain the code, and coupling it directly to the code.

In a way that it. It, as you said, makes it impossible to get out of sync. Because the artifact is generated by the code that's been written. And that, to me, is like, that's the game changer really. Is that, you know? As you said, I've spent days where we charted something, we went in for review, we got changes made and then we just had to go back. And we do, like multiple days of refactoring. All of this, these documentation and these plans and all this stuff, these artifacts that were generated not by code, but by us about code. And it just. It makes the whole development cycle so much more painful than it needs to be. And so I think that there's, there's something really exciting about this idea of, you know, not even laziness, but just consistency. Like, there's nothing better than knowing that everywhere you go in your code base is correct.

And like, nothing is a comment that's like, don't ever touch this, this is broken, but actually, that got fixed, and now you just have this straight comment that you're not sure if you should remove. And the person who did it quit, like three generations of programmers ago, so you're just kind of like, I don't know.

Play from 56:00

Maybe we just work around this instead of ever trying to change this code. Yeah, that's my biggest fear, too. Is just like the bus factor, right? The the, you know, when only one developer understands how part of the system works. And yeah, this is sort of like an insurance policy, right? The cost up front is big. You know, it's a big learning curve, but you're not learning anything specialized again, you're learning something that's existed for many, many years. And, like some people in the chat mentioned something that's present in many other areas of technology, especially game development and now even, animations. There's this really cool, animation app that I saw called Bride and drive, allows you to do just these really cool, sort of like rubber hose, or, you know, just really complex animations. And they're actually adding a state machine module to it, not using X8, using their own thing. But yeah, you could, like, transition between animations, with that, and like, Oh, that's really cool.

So it just goes to show you that they're basically everywhere. And it's not like, honestly, I fear learning something like Kubernetes because it's a very proprietary, you know, it's gonna be a large learning curve that's only good for kubernetes, right? But, if you learn state machines, you know, it sort of, is useful in many different places. Sorry, I'm rambling a lot about this, I have too many thoughts. No, no, it's totally like, I, I agree, and yeah, the um. Camilo asked if, if there have been episodes about this, absolutely, there have. We've got a few episodes on the show of, about state machines and using them for different things, I think that state machines are one of those things that, you know, they're. They're worth a longer discussion, because, as David said, the learning curve is a little bit steeper. And what you're what you're initially up against is a lot of. There's jargon, there's, ways that data is linked, there's, you know, a spec attached to it, but as you get familiar with that, it starts to, I guess it.

It's learning something that we're all doing intuitively now, and relying on intuition is perfectly. Fine, but it introduces risk and silo, and, as you said, the bus factor. I, as a developer, like, my number one thing is, I never, ever, ever want to be stuck on a project because I'm the only person who knows how it works. I never. I never want to get paged because I'm the only person who can maintain it. And that means that code needs to be communicated about. We need to be able to hand off all the things in our head. The best way to get promoted in my, in my opinion, is to program yourself out of a job. Do it so well and communicate it so well that other people can step in and do it. And then you get to, you get to advocate for going and doing the next fun thing, you know, I think the idea that you should make yourself indispensable by making your code hard to read, or like making yourself the only person who can maintain it.

That that's an idea. That, that one makes me sad, like, I really, I really wish that people would think about it the other way. Automate yourself out of a job by doing such a good job that anybody can do it, and by making your code so understandable. And I feel like state machines are a step in that direction. You're you're taking something out of your head and you're putting it on paper in a way that does not require nuance to understand. You can just look at it and step through it and get to where you want to go. Yeah, uh. In the chat, they were asking what the bus factor was. I guess it's sort of a morbid, description of what we're talking about. But if your teammates get run over by a bus and end up in the hospital in stable condition, you know, let's just hope for that. You know, it's, how many of them can get hit without, you know, having the project absolutely sabotaged?

A a less morbid way of putting that I like, is vacation tolerance. How many members of your team can go out before the whole, before all work grinds to a halt? And you know, if so, if everybody goes to a conference and two people are. Left on your team, can you continue to get work done, or are those two people just kind of hamstrung until everybody else gets back? That's a, you know, that's a. It's a bummer. Like, because I've been on teams where I had all this institutional knowledge in my head. And I would go speak at a conference or I would go on vacation. And I came back and nobody got anything done. And I felt guilty because I was blocking. They felt guilty because they didn't know how to move forward, because they needed something that was only in my brain. We all got in trouble because our velocity slowed down and, like every like, everybody felt bad about it.

And as I've moved more and more toward this model of, you know, socializing code and making sure that code is transferable and not building knowledge silos. Everybody just feels better and I've noticed that everybody on my teams is. Now that we trust each other more, we, we work better together, we're more collaborative and everybody's getting promoted. Like the last team I was on at IBM, we were really good at this. Every single person I worked with on that team has been promoted at least once since then. And that is such a cool feeling. Because it means that everybody had access to the knowledge and access, the autonomy to make changes. That let them demonstrate the leadership, that let them move forward. And that relies on this type of programming of making things accessible to people. Yeah, yeah, so I guess it is accessibility in a different way, you know, on the web way. But like, just making sure that everyone's in the same page, you know, at all times.

So yeah, yeah, yeah, this. This became a very philosophical episode in a big hurry. It did, it did. But I mean, I honestly, that's the whole purpose of this. Like, I, I didn't like, do this XState project.

Play from 59:00

You know, for the last few years, just to be like, you know what the world needs another state management library like that? That wasn't my intention, my intention was more about, you know, what we were talking about, the people factor, the just generating documentation and tests and all of that, and being able to communicate changes, and. Logic in a way that's really clear for everyone involved, and we're not doing that now. I think that, you know, state machines are still pretty niche, and that's why I appreciate everyone watching this right now. Because at least there is some interest in steam machines. And actually, I realized that, I know that steve machines are becoming more popular. Because people are starting to joke about it and make fun of it, which is a good sign. I, I, I didn't invent them. I'm not hurt about it, but you know, people are like, Oh man, we have to learn all these things.

And you know, front-end developers are hyped about state machines and whatever. It's like, all right, that's, that's funny, but I'm glad that, you know, that means it's getting more attention, right? Yeah, any news is good news. Yeah, so I mean, that's, that's the best sign, right? Is when people start teasing you about it, that means you're making an impact. Yeah, go back to three years ago, no one was really talking about state machines. So it's really enlightening to see. And I'm actually, really happy when people tell me, listen, I'm not using XState, but I'm definitely using those ideas of state machines and statecharts. And I wrote my own thing and I'm like, that's awesome, that's my goal. And that goes to show like this is not a proprietary concept, this is a, you know, something that you could learn once and use everywhere. Yeah, so a couple, moving away from the philosophical into some of the practical things.

I saw a couple questions come by in chat while we were talking about, implementation details. So as we look to roll this out, what are we looking at adding to our site? When we, like, when we, when we take on XState as a dependency, what, what type of, bundle size and like, what? What are we really looking at in terms of what changes functionally in our app? So, X8 does a lot, first of all. It has to adhere to the entire SCXML spec, which is pretty large, and it's doing a lot more than a typical state container would do. Just because, I mean, even if you go to the uh. You know, w3..org SCXML, you can see that there's a lot going on there. So, because of that. Right now, the package size of X8 is about the same as Mob X. You know, it's going to be about, 14 or 15 kilobytes.

Which, yes, it does sound like a lot. But keep in mind that it's also doing a lot of things that you don't have to do manually anymore. So, and for many projects, especially the projects that necessitate the complexity to use. X 15 kilobytes is really a small piece of the pie, like a very small piece of the pie, right? You're, you know, okay, 16 kilobytes? 16. And then if you look at Redux, but then you also add in like, Thunk, or what is it? Redux Thunk? And then you also add up, ending in Redux Sagas. And then you've got like all of these different pieces that start coming in and it is going to be a little bit smaller. But I don't think it's actually, oh wow, that, yeah, that's already like 15 kilobytes. But I don't think it's actually directly comparable, just because, um. X8 is not solely a state management library, it's a state orchestration library. So comparing XState to Redux doesn't make sense.

By comparing XDA to Redux Saga, that makes sense, and that's because the primary purpose of Redux Saga and related libraries is to orchestrate state changes. So, if there's one takeaway for your, you know, viewers, it's that there are two different types of state libraries there. State management, which is just like, here's a nice container, do whatever you want with it. And there's state orchestration where it's like, let's let's formalize how your states changes over time due to events or things that might happen. And again, Redux Saga is a great example of this. So, X day tree is also in that area, you have just Mob X where you could, just, honestly, Mob X is magical. But you also have MoBX D3, which adds structure on top of MobX, and it also has these, async flows as well. So this one is a 21.7 kilobytes, so that's why it's a different category, yeah, with. With that said, there's also, XState, Slash, FSM, and so if you're using.

Just flat machines, it's. It's under two kilobytes, so, if your complexity does not necessitate XD, use X8 FSM, it's going to be absolutely tiny, you know, under two kilobytes. And everything we did in here, this all works in FSM, right? Yes, that stuff does, the after, with the timers and everything, that stuff does not. So what we did, you know, with the animation, that's not going to work in FSN, but anything else. But we could do that. But we could do the same thing with like an entry, right, we could do like an entry set, timeout and then transition from there or something. So we sure, yeah, we lose a little bit of the built-in stuff, but yeah, the flexibility is still there to handle a lot of these types of things. Because actually, I didn't know that after existed. And I ended up using entry to do a set timeout in my state machines so that I could do like time transitions like that.

And those are, those are all like, but anyway, so if you're really trying to code golf this down, FSM is going to be pretty good to get you going. Also, I've found the things that you get to cut out of a code base when you move to. State, machines typically will more than make up for the 16 kilobytes you'll add with state, with XState. Just from my my own refactoring experiences, I've I've noticed that I got to drop several modules that made my life a lot easier. Yeah, I also posted a link in the chat. You don't need a library for state machines, it's the title of that, and that's because you don't, at least for simple state machines. And that's because you could express a state machine in any language, and people do like you go to any language. There's going to be many tutorials, articles and even libraries on, making state machines. Just because they are actually a common pattern, and so this article talks about just the progression of as your state machine gets more, more complex.

Here's some different patterns that you could use in code without having to introduce a library such as XState in order to. Create a state machine. But as you get more complex, I describe why you would actually want to use, libraries such as XState. And the reason is because when you're getting into nested and orthogonal or parallel states, it gets really complex to implement yourself. And that's it's sort of like date functions or Moment..js. If you still use it. That's one of those things where you do actually want to reach for a library, so you don't, reinvent the wheel. Painfully. Yeah, it's one of those things, it starts easy and gets really hard, really fast. I feel like that's, that's been my experience with a lot of things where I'll look at it and I'll go. Oh, well, we don't need most of that. Let's just let's just build a simple version of this.

And then it falls off a cliff. The first time that you hit an edge case and you're like, Oh, that's why people use this library, exactly. And so I think that that is. But this is really interesting because I like how you're building up to it, right? And kind of showing where does the complexity come in and how, you know, at what point does this really make, make the most sense? But I, yeah, I love this, like, I also just like that. You know, even as you're, you're not using XState, you see familiar things in here, we see states, we see an initial state, we see what the actions are. So even without using XState the library, we can still reason about this using the same like set of logical deduction. That we would use if we were, if, you know, if we were using XState. And so it still creates this common layer of communication, yeah, yeah, and uh.

As a bonus, you could copy paste into the visualizer and have that just work. And that's also the reason a lot of people, really, for whatever reason, don't like the object syntax of XD. Which I understand it feels a lot like configuration. But that object syntax, like you see here, you could use without XState. And then it's just reading key value pairs from this machine dictionary, or, however you want to consider it, and, you know, you could just write a simple function for that. Very cool. And if you didn't want to use an object and create your own functions, you're basically reinventing XState and doing all that. So, you know, that's why I like the object syntax, it's comprehensible, yeah, the the ability to make it copy-pastable like that and to. You're describing your data or your state in such a portable way. I guess, yeah, that feels really good, like I, here's what I like about it.

What I like about it is that in previous episodes on this show, I've been able to go to the visualizer, build my state machine and then copy paste it into my code. And not have to do a bunch of fiddling with it to get it to work, you know, you can, you can really do that flow of like work in Codepen and then copy paste it out of Codepen into the component at work. And then you can, like, kind of plug it in there and then it gets more complex. But if you need to share it with another thing, you copy paste that into a shared component library that gets published as a package. And then you can. You know, it just becomes so much more portable than, like, okay, I've got 15 utility functions that do different boolean states, and then I've got, like, my. A bunch of transition logic tucked away in this utility package.

And a bunch of, like, show, hide stuff over here, it all gets very, very hard to manage very quickly. Yeah, or, you know, maybe in the future. Even having a visual creator where you just drag drop nodes, make your state machine visually, and have that spit out. JSON where you could use anywhere, which, by the way, is something that I'm working on. So, even if you dislike the whole object syntax, just keep in mind that. It's sort of a necessary evil. For something like a visual editor, where you don't have to go at all that I'm excited about that. How does? How does one, get onto the mailing list for that?

Play from 1:05:00

Well, I have a newsletter Stately.dev. I actually send out newsletters very infrequently, so only for very important stuff. I think that there's five so far, the next newsletter that's going to come out is going to. Be, like a teaser slash preview of, you know of the upcoming creator? So I don't know what happened. No, I think it worked. It goes through buttondown.email, so yeah, I think you already registered or something like that. Okay, yeah, so I'm in, I'm in. I want to see this because it sounds like exactly what I'm looking for as a way to, because that makes it collaborative even further. So now our design team can work with us to help define app states. We can, you know, and that unlocks the store to now. Holy crap, what if we plug in from there to like Figma, right? So now we get clickable prototypes based on state machines, all in a way that translates into the final product code.

Like this is some next level stuff, there's, there's so much potential here, right? Yeah, I have way too many ideas about this, including, like, something that I realized that I, I wanted this years ago. But all the reducers we make for Redux or Vuex or whatever. It's like, I just want some registry of them where it's like, Oh, I want a pagination reducer, or I want some authentic authentication reducer, you know, substitute reducers for machines. I would love to just pull one off the shelf, customize it to my needs and use it, knowing that someone has already worked on it and made it like bulletproof. Instead of having to write all that logic from scratch. Because I think 99 of the reducers that we do write, and 99 the logic number one we write manually. Number two has probably been written thousands of times before, in some form in other projects.

So, yeah, nice, yeah. I think I just realized in this exact moment that I broke my email address. I was like, why did it say there's no MX record? I know why there's no MX record. I transferred my domain, my email is broken and has been for almost a week now. I hope nothing important happened. Great, great, exciting. Okay, so David I, I am. I am so pumped about this, I'm so excited to see more about kind of just where this goes. As this grows in popularity and more and more people start to understand the power of what this unlocks, right? Um? With that in mind, where should someone go if they want to take next steps? With XState or with state machines in general? Well, there's a few places, of course, there's the XState documentation. You could follow me on Twitter because I tweet about state machines way too much. And we also have a Discord community, so Discord dot GG.

Slash XState was very happy to get one of those humanity URLS, so just go slash XState. And yeah, actually, that's a really. I've been surprised. It's a community that has we've only started, like, I don't know, about a month ago, and it's already grown to over 600 people. Just really curious about this stuff. There's many sections for help, whether you're using TypeScript, Reacts, views. Felt just anything. And there's actually a lot, a lot of people there besides me, who are willing to help there. And we also have ideas showcased, lots of resources. Just, there's always an interesting discussion happening in Discord. I'm really trying to sell this Discord community. It's great though now I'm. I'm really excited about. I've. I've loved Discord as a as you know, I'm I'm part of the party Corgi Discord. Which is a great place. If you're just trying to learn how to, if you're just learning, if you're creating things, any, any of that kind of stuff, it's it's super fun.

I don't remember what the what the command is if somebody wants to drop that link, but I've loved it as a place to go. That's like low stakes, it's not a Slack group, it doesn't, you know it? The the content is, moderatable, there's voice rooms. And I'm a big fan of Discord, I guess a lot of people are a big fan of Discord. Since they just got acquired by Microsoft, right, that was, yeah, they're not acquired just yet. There's stocks to, you know, make it part of Microsoft, which I work for Microsoft. I don't like teams, so hopefully it's sort of, I don't know if it's going to replace it, but make it better or something like that. Yeah, well, it would be good to see some real competition in the workforce to slack. So I'm, I'm. I am excited to see, what kind of innovation that. Drives, so, you know, good, good on them for doing a doing such a good job that they could get at what.

A 10 billion dollar acquisition, holy crap, hey, that's a that's a bargain. Remember that Slack was acquired for 28 billion? Oh my god, I can't even those numbers don't even process in my head. It's a buy one, get one offer. Oh wow, yeah, excellent, all right. So, with that, I think we are. We are just about out of time and I think we've hit a pretty good natural stopping point. The chat is, here, here we go, with just so many corgis. But yeah, y'all, thank you so much for hanging out today. This has been super fun. David. I really appreciate you coming on. Again. This is always great. I love talking about not just the code, but the why of the code, and I always enjoy talking about that with you. Do you have any parting words or final websites you want anybody to check out? No, I think I said everything. Thank you so much for having me on the episode.

You know, it's been fun as always. More qualities than last time, but, you know, a lot more corgis than last time, that's for sure. Chat, remember? As always, this show has been live captioned. We have had Rachel here with us all day, doing the live captioning, which is on the learn with jason.dev homepage. She's here from whitecoatcaptioning. And that is made possible through our sponsors Netlify, Fauna, Auth0 and Hasura, all of whom are kicking in to make this show more accessible to more people. So, chat, thank you so much for hanging out with us today. Make sure you go and check out the schedule. We've got so much good stuff. You know, we've got, we've got AVI coming on. We're going to do more state machines, but this time we're going to do it on Kubernetes and let's see how that goes. Then we're going to do, Builder IO, which is a kind of visual builder for doing, Shopify and next, and it's it's gonna be really cool.

I'm excited about that. We got prints coming back to do real time Twitch notifications with the event sub. API that's gonna be a lot of fun, there's so much good stuff coming. Make sure you go over there, check out that add to Google Calendar button. And it's going to be, it's going to be so much fun. All right, y'all, we're going to go find somebody to raid. David, thank you again for hanging out. We will see you next time. All right, thank you for having me.

Play from 1:16:00