Modeling Application Logic Visually

[Music] Hey, awesome, thanks for, thanks for having me. So, yeah. Today is gonna be a little bit of live coding, a little bit of live not coding, and you'll see what I mean by that in a minute. So, first of all, a little bit about myself. I live in Orlando, just like, just like Ryan here. But I am wearing a jacket because it's cold inside my house and he's wearing a t-shirt because I guess it's not cold inside of his house. I don't know, maybe the air circulation or whatever is bad here. Not sure why there's a discrepancy, but anyway, uh. I have been a software developer for about 10 years and I've been very interested, for most of my career, in state machines and statecharts. Of course. And the reason that I'm interested in this is because application logic can get hairy, especially as you add more features and more requirements and specifications. And I suffered through this when I was a junior developer.

We had, like all of these complex workflows where you go from step to step. And like, just trying to organize all that logic, especially as you need to add features. It just got really confusing over time. And it seemed that with normal programming languages and the way we normally, develop things and frameworks, that there was no really good pattern to do this. And so that's why I took a time travel trip back like half a century and researched this thing called state machines. And so what's cool about state machines is that they're a visual formalism, which means that they could be visually represented in their formalism, so they're visually exact. So technically, you could take those diagrams and make them, you know, into something executable. So it's sort of like drawing code or diagramming code instead of actually typing out code. Which seemed like sort of a fantasy to me at the time. But that's why I started X data and wanted to just dive into how we could, make something visualizable and also executable at the same time.

Play from 0:00

And so I'm going to be describing like concepts of state machines and statecharts, and also how X8 works. By doing an example, and so the example that I want to do is. A a pretty simple example, this is a video player like you would see on any landing page. And you could just imagine this as a specification or requirements that you got to implement in an app. And so we might have user stories, like, and I'll just type them out here as a user. You know, the I'm not going to type out the full specifications. But, the video player should be minimized at first, so right now we see this video player. It's like an image, and then, when I press play, then the video player. So video should be maximized and it should start playing. So that's where the behavior that I want, like, I don't want to play in this small thing over here. I wanted to do the thing where it sort of goes full screen and then it, it starts playing.

And I'll actually show an example of that I just saw, because this is actually a pretty common pattern, in. In the Elgato website, there is a trailer video so you could see this is just an image, but once you click watch the trailer, it sort of goes full screen. And it starts playing the video right away. And so this video is playing. And if I press X, it's going to do a few things, it's going to stop the video and also, you know, minimize it. So when I exit the video player, it should, it should be minimized, and it should stop playing the video also when the video is done. And you know, obviously we don't want to keep staring at, you know, the last frame of the video. That's not very useful. The video player should be minimized automatically. So this is just an example of the series of user stories that you might get in, you know, one of your applications that you need to implement.

And so our job as developers is basically to translate these user stories into actual code. And you know, the way we would do this normally is just looking at this and be like, Okay, we could have a boolean. Like, let is playing equals false, let is minimized equals, true at first, and just all of these, all of these, you know, variables, that's just. You know, you know, just determine the state of, you know, that part of the application that we're working in. But instead using these boolean variables, which, you know, definitely get messy, the more you, the more you add boolean variables. I propose using state machines, and so here's how state machines can make things like a lot more visually clear. So, we're going to take the same requirements. And usually I would go to Excalidra or something like that, but this time I'm going to go to Stately..ai. Slash editor and so when you go to this website, you're going to be thrown into this, this visual editor that allows you to create state machines.

And don't worry, I'm going to teach you, like, what state machines are if you're not familiar with them. So a state machine is comprised of a few parts. The three basic building blocks of a state machine are states, events and transitions. So a finite state machine has a, you know, as you could probably guess, a finite number of states. In this case, we have first state and second state. Now when I say states, I'm not talking about any data such as, you know, the length of the video, or attributes like that, I'm talking about behavior. Like states that can that can contain the behavior of a component of your application, for example, one state could be playing in, one state can be paused. I'm actually gonna make it lower case, that's just my style. So, it could either be playing or pause, and the application is going to have different behavior in whether the, the video is playing or paused. And so that behavior can be things like what's happening, what side effects are being executed, and you know also what events are possible from that state.

So, for example, if your video is playing and I'm just going to call this video player anyway, if your video is playing, then you could pause it, you could stop it, but you can't play it again, like, playing the video again makes no sense if it's already playing. Same thing with pause, if the video is paused, you can play it, but you can't pause the pause video. I mean, you can, but nothing should happen. And so there's. Like at best case scenario, like doing events where those events shouldn't do anything, it's just redundant. But at worst case scenario, you could get into some really serious bugs. When a user tries to do an event in the states where they're, they shouldn't be, able to do that event. We saw this, I guess, a few years ago with the iPhone FaceTime bug, apparently. Like, when you started a video call and you added yourself to the conversation or just did a series of actions.

You could listen in on the other like to, to the other end of the of the phone call without the other person accepting the call. And so that should be an impossible scenario. Another very common use case is when I'm submitting a form and I press that submit button, or, you know, whatever the button says. And I'm frustrated because it's taking a long time and I click that button a million times. It should not make another request, like either the button should be disabled, or, it should just not handle that action. But what ends up happening, and you could try this out whenever you see it. Next time is that it ends up making a ton of requests to the server and so, you know, you have to defensively program to prevent against that. But using a state machine is just a really natural way of containing those different behaviors.

So in our video player, we actually have a I'm just going to call it closed and open states here one minute, or actually, let's call it, mini and full. So we have our states and the these are just like, the two basic states. The. The video player is either going to be small and collapsed, which is the mini state, or it's going to be full and expanded. And by the way, I already have some styles over here that we're going to be using later for when the player is full. How that should look? So yeah, that's states. Now there's events, and transitions. An event is something that causes transitions. An event is an occurrence of something happening. So, for instance, in the in the mini states, we could have the toggle event. I'm just going to call it. Toggle and so when the toggle event happens and we, we don't need to know the exact details of how that toggle event can happen, we just need to identify it.

Somehow. So we have toggle, it goes to the full state, and then when we toggle it again, it goes to mini. Or you could call this closed or something. These don't have to be the same event, I'm just demonstrating this with the same events for, clarity. So now we could simulate this and see that. When we're in the mini states and the toggle event happens now, we go to the full states again. If we're in the full state and the toggle event happens now, we go to the many states. So, what's cool about using this is you could actually export it to JSON, but I'm going to code it up manually just so you could see how you would use XState in order to express this state machine, which is a model of our application, directly in code, so, obviously you need to have XState installed, and that's pretty much the only dependency.

We're not going to be using any frameworks in this demonstration, I'm just going to be showing you how you would do it with XState. And we're going to go old school, even before the days of JQuery and all that. And use document.getelementsbyid. Really useful stuff to know. You know, I. I always recommend everyone brush up on their like core basic web knowledge before jumping into frameworks or libraries, or, or things like that. So I'm going to import. It's called create machine from X8, and so we're going to create a machine that basically describes these user stories and eliminates the use of boolean variables. So we're going to make a machine, I'll just call it machine equals create machine, and this is going to. We don't need to give it an ID, but I'm just going to show it here to, just for clarity. And just because this looks nicer in the visualization.

And so we need a few things in our state machine. I described that three basic parts of the state machine are the states, the events, and the transitions. But we also need an initial state, or we need to specify what. Is the first state that the machine is always in when it starts up? In this case, it's Mini, so now we have a couple of states, we have Mini. And I'm just going to make this an empty object for now. And we have full. So, this is our, this is our state machine, and now we have to actually transition, between those states. So that would be on, toggle full and full, when we toggle, so on, toggle, we go back to mini. All right, cool. So, let's, let's just verify that this works. I'm going to first. Console.log the machine dot initial states dot value, and so this is going to be the finite state value of that machine.

Ignore this first line over here, but yeah, we have mini right over here. And so if I, have. Next state equals machine.transition from the first date, so the machine.initial state, or you can put undefined. It's up to you, and we pass in events like toggle, let's console.log, the next state, oops, nextdate.value. So now you're going to see that it transitions to full. Let me show you that again. Okay, it's not going to do it, but that's okay. So you could useMachine.transition as a peer function to basically determine what is the next state. When I have a current state and I have this event. Now. You might be asking, isn't this just really similar to Redux? and the answer is yes, it's like Redux. With rules. You could consider machine dot transition to basically be a reducer. So now let's make this alive and by alive. I mean, not just as a pure function, but as an entity that's actually holding its own state, receiving events and updating its local states.

You know, based on the events that came in. So the way we do that, we have to import one other thing, which is interpret. We're going to interpret this machine, so, I'm going to call it a service interpret machine. Sorry, dot on transition and so this I'm just adding a listener. So whenever the state changes, I'm going to console.log the state.value and then we're going to start it. So, right now it's just going to log Mini because it is in the mini states. But I. Actually want clicking this to, you know, to toggle it? So sorry about that. I don't have corona, I promise you. So I'm going to add something here. This is like one of those get the kick out of the oven things, but yeah. So we're going to add an event listener to the player, which is this, and so whenever we click it, we're just going to send that's toggle events to the service.

So the reason we're doing this is so you could see what happens when we click it, which, is nothing. Right now. Let me just make sure that I have the right stuff. We have the video, we have the player. Yeah, let me just inspect this real quick. Okay, so here's our player. Debugging is always good, okay, so we have the player. And you know, we want to send that event. Let's just make sure it's being, captured. So console.log clicked is okay, there we go. I don't know why it wasn't, showing that, but yeah, you could see when it's clicked, it goes from mini to full to mini to full. See, so you can see it's going back and forth. That was really weird. It's like a bug that solved itself, that, like, you know, couldn't figure out why. Okay, so, what I really like about on transition is that you could actually impart side effects in here, you know, just to quickly test things out.

So what I'm going to do is, add that attribute, the state attribute. I'm going to add the state out value to that attribute, so state.value. So this is going to appear on the elements as data states equals mini or equals full, and so it's going to change that value. So now when I click, you're going to see it goes to full screen, and when I click the player again, it goes to Mini. So we have that part of the behavior working. And so that, like, is one of the most basic state machines that, that you could create. And so I, I know some of you might be asking like, Okay, why would I do this? You know, I could just use a boolean for this, remember, we have other requirements, and booleans don't really. Scale for these requirements, and I'm going to show you, how state machines can evolve to become statecharts and become a little bit more powerful.

So, remember, that's one of our requirements is that when the player is full, we want this video to actually be playing. So we could do something called adding nested states, and so I'm going to, actually, no, I'm not going to add nested states. That comes later, but we are going to add another statechart feature, which is actions, and so I could say entry. And I'm just going to do video dot play. Really nice API, you know, this is a video element, so we could just call dot play and it's going to play and it's pretty awesome. And so exit via video dot, yeah, dot pause, because we don't want the video to keep playing. Yeah, so let me demonstrate, like, what exactly these entry and exit actions are? So an entry action, so I'm just going to call this play. Video is executed whenever you enter a state, and same thing with an exit action, so whenever you, whenever you exit this date, you pause the video.

And so the reason why these are important is because there's three types of effects. That you could do, I mean, they're all the same, sorry, three types of actions. I meant there's entry actions, exit actions, and transition actions. The ones that are probably going to be most common are these, are these transition actions? So I could have put play video over here, and so whenever this transition is taken, it's going to play the video and go into the full states. So the reason that you would want to use entry or exit actions is when you, basically to dry things up. So when you see, there's a lot of transitions and every single one of these transitions going into the full state plays a video. That's your sign that maybe you should move that action to the entry and same thing, with exit actions and things like that. So, yeah, let's, let's see if this works.

I'm going to reload just to triple check, it's going to transpile modules and do all that, and so when I click here, it's actually going to. Play the video and so if I exit out of it, it pauses the video. So, you know, it goes here and it works just the same. Okay, that's awesome. There's something else though, that I want to add when this V. And of course, it's part of our specification, too. When the video ends, we wanted to, go back to the mini state. And so this is what I mean by, like by having those entry and exit action. So I'm going to call this video dot ended. So when this happens, we also want to, I mean, obviously the video is going to be paused, but we do want to go back to the many states. And so you could click, simulate, real quick, say, toggle, and let's say I'm watching the video and the video ends.

Okay, we verify that our logic is working. So, let me go back here, and so we're gonna do video.ended mini. And so what's great about this structure, by the way, is that, you know, you could change these transitions. So let's say that. After the video ended, you wanted to pop up a form that says, what did you think of the video? Or enter your email to find out more information. Or something that does something different. So now instead of like, diving through the code and figuring out where to change that thing, you would just change it right here in the transition. Now. That video that ended, is going to be we could hook up that event here, so video that event. Listener ended. I love the video API, it's so straightforward, service, dot send, and we could just send the video dot ended event. Okay, so now we can see that when we play this, it's going to go in full mode.

Thankfully, it's only four seconds and when it's done, it shrinks back down. So this is exactly what we want. And, you know, just for more measured, like, let's say that we want the video to, to close. When you press the escape key, so p dot, escape mini, you know, same sort of thing. And then we could just add an event listener. So I'm just going to do that right over here, so that whenever the escape. Key is pressed down, we go back to the to the mini state. Oh so, I forgot to press the escape, so I'm going to press escape. And you can see that, it just went back, to that state. So that is a very small demonstration of how this little thing can express like logic of, you know, your complex applications. And just one more thing to show you while we're working on, making the brand's new Stately visual editor, able to visualize applications.

We already have live inspection utilities that you could use. And so, if you import, inspect, oops, inspect from XState and then we, inspect, URL just daily..ai slash fizz inspects. I think that's what it is. And I'm going to do. Iframe false by default, the iframe is true. But right now we just want to pop it up in a different window and then we just set dev tools to true. Then this is going to show you the actual, you know, basically the same state machine that we created over here. It's going to auto lay out it and make it look nice. But you could see that's going like from mini to full, and all of that. And so what's really cool about this is that if I interact with this application, you could see it's in the full state. And right now it's going to go back to Mini because the video is going to end hopefully. Oh wow, does the video pause? Like, while I?

Okay, so you see, it just went back to Mini and it goes back to Mini. Over here as well, you could see the log of events over here. And so, basically, you have an inspection tool that you could look at in real time with the state machines you're using for your application. Now. This, of course, is doable with a reducer, but then the biggest thing that reducers are missing is a way to declaratively specify which actions or side effects are supposed to be executed. And so that's something that statecharts really excel at. Plus, this is a lot more concise than having to have switch statements or nested switch statements. So, yeah, you could just think of this as a super powered reducer, but that's. An overview of how XState can help you visualize and visually creates your application logic. And I'm muted, like, really, I didn't realize you were done yet. So I was like, I was like, ready for the next part.

Because that was awesome, I could go on for hours, but you know, no, that was, that was really cool. I. I love the little debugger that was, that's, that's awesome. See so, under. Normally, if you have it in the iframe, is it going to be just like showing it like at the bottom of the page or something like that? It shows in an iPhone? But you have to like, style the iframe and put it somewhere on your page. Like, there's a lot of extra work. Yeah, but like, so it might not be worth it to do that. But you know, I think all you really have to do is do iframe data XState. And actually, let's see if this, oops, can't do that. I do that, I forget this is not React. So, if I. If I take this out, then, yeah, it'll show in a very, very tiny thing. So you have to like, just and hide and everything.

Yeah, yeah, yeah, that's that's really cool. So, so we got a number of questions. Yaroslav asks. How much of your app do you recommend putting into? XD? That's a really good question. So I, if you have a new app, like you know you're completely greenfield, then, uh. Using something like X8 can be really useful, even just as an organization tool for understanding. What are all the events that could happen, what are all the states that I could be in? But, honestly, X8 is not, something that you have to use like everywhere. It's not like an all-in type of thing. It's something where, let's say that you have an app or a legacy app and you have a new component that you just want you. You have some special logic for it. You could use X8 just for that tiny component, so it's not meant to be something that dictates the entire state of your application.

Play from 2:00

It definitely could do that, and that excels at doing that, but you could use it at the tiniest level to the. Biggest level in your app, okay, so you, so that you, even you could incrementally adopt it. Like, say, I just want to this component for now and then over time to kind of transition the application to use it right. Yeah, awesome, yeah, that's, that's it. I think we kind of in my experience, like when I'm building this stuff. Like, you start adding states if you, if you don't think about this ahead of time, you're adding states that kind of without giving much thought to it. To like what the different states of a particular page or whatever part of the application are? And then, and then, you know, you end up, that's where you end up with those kind of problems you described, where it's like, I didn't really think about, like, Oh, I just sat there and I'm like, Okay, I need to. They asked me to add this in, so I'm going to go in and add it.

And then realize that conflicts with a different state and we end up with a mess of something. So, so I my thinking there is like, it's probably good to add this, even when the states are simple and you don't have many. But at least then it can. It can grow without, without causing problems, right, right, exactly, I, I say. Like, a good rule of thumb is if there's any possibility that you might have, like, you know, say more than two states in your application. Because a lot of people say, I don't need X8, or I don't even need state machines or anything right now. Because my application is so simple, and to that I say, applications don't stay simple, and the applications that do stay simple. There's going to be like. And there already is like an infinite number of tools that could already like, do those kinds of applications, you know, like those simple card applications, which even those have multiple states in them.

But, you want to, code in a way that lets you scale complexity over time, not in a way that's just like the easiest way to do it.

Play from 27:00

And that's why, you know, people say XA is a bit of a learning curve, which it is, but you're not learning XD, you're learning state modeling and state machines. And event driven architectures, all things that are really useful, whether you're using X8 or not. Right, right, yeah, I mean, you know, granted, you know, XState better than anybody. So it was easy to watch you do it, but it didn't seem that difficult. So I, I, you know, it definitely seems like something wouldn't be that steep of a learning curve, right? You know? Okay, we got a bunch of other questions. So, Jimmy asks, what are your thoughts on how this aligns or differs with RX? These seem to solve similar issues in terms of state and derived state. Do you agree? When would you use XState versus Rx? When would you combine them? So, first of all, I'll say that X8 actually works pretty well with RxJS, the interpreted machine.

So this service over here is actually subscribable. You could do, you know, with RxJS, like on states equals, from, and if you know RxJS, you know what this from is, so from service. And then you're done, you also have service dot subscribe if you want to subscribe directly to it. And it takes either an observer or, you know, those functions, RxJS has a pretty interesting function signature for that, causing some issues, but, you know, it works, so you basically, this is subscribable. The biggest difference, though, between something like this and RxJS is RxJS. You have a source and you're listening for emitted values. You can't really talk back to an observable. That's unless you know you do something weird, like have a behavior subject that, forwards those events over to a scan operator or something like that. But that's not really a first class concept. I would call like these things, which I call actors, it's very similar to the actor model.

I know people have a very strict definition of that. But these are things that are observer or, sorry, observables, and things where you could send data to so you could send events, receive events. And it. It's like an, it's like an observable that could also spawn other observables too, so they're, it's sort of like super powered observable. Okay, all right, I don't. I don't know a lot about RXJSo, so a lot of that was over. It made sense to some. People, hopefully, hopefully. Jimmy, you got your answer? So? Linda asked. I would love to hear if the visual tools would potentially be open to other state management tools in the future. And GRX maybe, I love that question. Yeah, we were actually just talking about how, like within our team, how this could maybe take like a Redux producer or something from, like you said, NGRX.

Play from 29:00

And at least, at the very least, visualize all the events that are possible. Because, most of the time, the way that those state management libraries are, they don't have finite states like this. They have a bunch of Boolean variables, or you might be defining these ad hoc with like a status enum or something like that. But at the very least, just having this and being able to simulate it is pretty nice. So it is one of our big goals, and also the visual editor, we have much bigger goals than just having this as something that could visualize XState machines. We want this to be the directed graph tool for anything that can be represented by a directed graph. And it turns out there's a lot of things like that, like even GitHub actions, CICD, pipelines, workflows, different things like that. So we want, both different inputs to this, and different outputs as well.

Like being able to express this as a an SVG diagram that you could put anywhere. We have a lot of big plans for this, so the answer is yes. We're thinking about other state management tools as well. Cool, yeah, I love your idea of the GitHub actions because I found when I when. I tend to write those like kind of understanding all the different parts where the when they get complex can be hard to visualize. And the writing when you write it out in GMO or whatever, it's just not. It's not hard. It's, you know, trying to wrap your head around. What the heck is that's going on with the logic? Yes, it's difficult. Nice, that's awesome. So Michael asks any reason to do play and pause and entry and exit on one state, not entry on both states? Well, you can honestly this state modeling, or like modeling your application logic is more of an arts than.

A science? So, some people might want to just like, put this play video action on toggle and put pause video on this toggle that goes out to Mini. Or maybe this video ended thing, or maybe something else like the Key.Escape thing that we saw. It's really up to you. So, honestly, it's one of those things where you have to just keep modeling stuff, see what's best, but modeling is better than not modeling. And so the way we typically code applications, we forget to plan stuff out like that. But at least now you have a visual framework for, oh, I could put this here, or I could reuse this over here or something like that. Okay, okay, that makes sense. Yeah, um. Jimmy also asks, are there XState integrations for native mobile? So, I do, native mobile. It depends what you're asking, like, swift and swift, and Android.

Not quite yet. I, I know that we do want to support different languages in the future. People have used XState in React's native applications, though. And anywhere that JavaScript is a target, you could also use XD. It has zero dependencies, it works server side, browser side, you know, wherever you want. So in the future we'll support other languages and bring, you know, frameworks too. Okay, yeah, so, right now it's just JavaScript, right? Like the export anyway. I mean, you could visualize any anything here, but the export would be just for like, something that can consume for XState JavaScript. Okay, that makes sense. Okay. So Kyle wants to know, can we get the code for the example you gave? Yeah, I'll, I'll share it. You know, just I'll, I'll give you the code sandbox. And you could distribute that however you want. Yeah, we could just throw it in the chat here.

If you want to throw it in our chat. And and I'll I'll copy the link over and put it in the chat here. Okay, let's do that.

Play from 32:00

Yeah, awesome pal, that was an easy question to answer. So? Kyle also asks, would you have multiple state machines in the in a single page app, or just one? Oh yeah, you definitely can. And that's also one of the biggest, deviations from. Things like UX, Redux, NGRX is that there's no global like huge mega reducer that controls all of your application. Logic. That's just not practical because you have local state, you have global state, but you also have state that's in between, you know, shared between components, but not necessarily, global or local. And so with XState you could have many machines, you know, for different parts of your app, and those machines can also talk to each other. And so that's what we find a really powerful part to all this. And that's a part of what's called the actor model, which I definitely recommend, reading up on, and so it turns out that, you know, the actor model is actually really useful. In front of applications where a lot of things can be happening at the same time and different things need to talk to each other.

Okay, so right, so would you typically have, like these machines, be per component? Or, yeah, you can, you can do that, but I just want to note that it's also possible to have that global machine at top and have other things listen to it and send events to it. Okay, again, it's, it's a modeling question. It's really up to you? Okay, well, you and your team, right, right, right. So, but when you, when you do it, what do you? What's your usual? Like? You usually have that global one? And then, well, yes, so I will say, like, even in the visual editor and the visualizer, all of these are using XState, of course. And, we do have multiple machines. For example, you know, we have a canvas machine over here. We have a it's called a press session tracker machine, just to track the interactions here.

Play from 36:00

We also have state machines for even the smaller things, like these inline labels and things like that. So that just gives you an example of how all these machines do work together. Oh yeah, of course, we have a machine for controlling simulation as well. Okay, yeah. Jimmy has asked again, is there a first class idea of acing? Transitions betw between states, or do you split transition into started ending events? States? Think specifically about animation as a result of a transition? Yeah, so um. State transitions are like, by definition, and we can't change this because it's the mathematical definition. They're zero times, so you conceptually, when a transition happens, it goes directly to another state. However, that doesn't mean that you can't express animations, and actually, animations are really awesome to express with state machines. Let's say that you want an animation here. I could have a state called opening and so on, toggle, we could go to opening and you know, after like two seconds, then we could go to full.

And so you could actually see that over here. This is actually pretty easy to demonstrate. But if I click here, it goes opening for two seconds and then full. And then. So, you could just imagine that opening is some sort of animation or something like that. So yeah, instead of saying that this toggle is an acing transition, because that's not something that exists. You would have a state that represents that in between states. Okay, okay, that makes sense. And so that middle state would actually like change. Whatever trigger the animation, it, or would it be kind of, yeah, yeah? So you could even do something like, entry, play, open animation and then like, after some time, go full.

Play from 38:00

Or you could even invoke something where you know its source is open. Like, we'll figure out the details for that later. And then when that's done, you go to full. And so, that, that's how you could express that. Oh okay, wow, that's really cool, all right. Mikhail asks. Where can he get this cool, Stately jacket like that? He wants some XState merch. Yeah, that's, we. We actually don't really, you know, sell this. This is just something that we had for our team. But I guess, you know, a lot of people have been asking, so maybe we could, you know, try to do that. But, we do have other swag. So if you find me in person or whatever, you know, we have XState stickers to give out, so, very even Angular ones as well. Well, maybe for those folks in Orlando. If you're at one of the ODEVs coming up, maybe they can get some XState merch there.

Yeah, stickers at least anyway, and. Then we'll, we'll, we'll, we'll wait on the on the jackets they look. It looks nice though, but you know, I got long sleeves on. It's not like I'm wearing it, it looks like a t-shirt. So I'm like, yeah, I mean, it's, it's not. It's not that cold, but it's not warm. Yeah, yeah, it's cold. For Florida, it has been for a while, hasn't it all right? So it looks like that's everybody's questions answered. I really appreciate all the questions. This was great having a conversation there, after everybody seemed to have a lot of questions, particularly Jimmy. Jamie. Thanks for all the questions. Anyway, David, thank you so much for this presentation. It was really, really cool. You know, I think I hadn't checked out XState. Honestly, I didn't know a lot about state machines, other than the little bit I think I've heard from you present before.

So like, it looks really awesome and definitely something I want to check out. Awesome. So yeah, so thank you for that. And Stately, the editor looks, looks, looks great, too. Congrats on the open beta.

Play from 40:00