XState: Making Application Logic Visually Collaborative

Same for the YouTube peoples. So I'm going to push that button now there we are, so good morning, good evening. Wherever you're joining us from right now, welcome to Nordiff. My name is Alex. I'm going to be getting out of your way as soon as possible. Just got a few formalities to get out of the way. We welcome David this evening. I'll let him introduce himself. Going to be talking about XState and state machines, making application logic visually collaborative. But I will let him explain more. Like I say, I'm gonna get out of the way aSAP, hosted by you. We're always looking for new speakers on that topic. Thanks to Damian for bringing us David, this evening. If you or someone you know, would like to talk, or if there's someone you wouldn't ask to. Just basically hassle, deploy Alex, and I'll go and hassle them. Next month we're having a bit of a follow-up to our last Christmas, bit of a different theme, basically.

The James Webb space Telescope, so we had Roger from Norwich Astronomical Society come and talk to us about the planned launch. Join us for the launch. We'll, be, yeah, streaming the live stream, but all on the Zooms. Uh. We'll be chatting about the launch and hopefully it goes well, fingers crossed. The launch is at 20 past 12. I think we established it was going to take about 30 minutes. So join us at 12.. The details are on the meet up and then we've just confirmed actually from Roger. They'll be joining us in February to discuss what's happened so far. So more. To come. Virtual social Club every Friday on the Discord 5 30 p...m. Join us to play some games and chat about your week rage about things quick. Thanks to the user story for just sponsoring that exact Discord. If you're in need of UX, or, user studies or research, or you name it, go and speak to the user story.

Sponsors, we're still looking. Give us a shout if you want to fill that space. And on that note, a big shout out to patrons who have literally, well, yeah, literally kept the lights on. We usually rely on our conference, which, for. Reasons got cancelled this year. It's back. You didn't hear it here? Well, you heard it here first. Potentially, uh. But June, we are planning for 2022. So, yeah, watching space. But anyway, like I say, I'm going to get out of the way because nobody came to hear me talk. I'm gonna hand over to, David, and yeah, thanks for joining us, all right, thanks for having me. So, yeah, my name is U.H. Deepakshi. I guess I'll go ahead and share my screen, because I actually have a presentation. So, let's see advanced sharing options, man. It's been a while since I shared using a zoom, so give me one moment there we go.

Play from 0:00

Awesome. Okay, so yeah, my name is David. You could find me everywhere on the internet at David K. Piano. My last name actually isn't piano, it's Coresheed, like it's spelled over there. And I work at Stately. I founded Stately. It's a company for, doing software modeling and providing services and tools for that, and, just making developments a lot more collaborative and productive. And that's, you know, sort of what I'm going to be talking about today is how we can make application logic visually collaborative. Before this, I was at Microsoft for about four years, so I got to wear lots of hats, do a bit of everything. Yeah, but now, of course, full time at Stately, so, yeah. One of the biggest inspirations for this talk was actually this quote that I read a while back, and you all probably heard it before, too. It's that code is read much more often than it is written, so plan accordingly.

And I know it's an adaptation from another quotes by I think, Uncle Bob Martin or something like that, um. But the meaning of this quote is, traditionally, considered to be that. We. We read code, of course, more than we write it, and that's just the way things are. But the way I interpret this is that we read code much more often than we write it at a necessity. And unfortunately, th this is, you know, just the status quo to date. Where, the like. The code we write is really an encoding of all the specifications in our app. It comes from user stories and it's. Distilled in there. So that when developers come to a new project and they have to figure out, okay, how does this work? What are all the features and everything that a user could do to this app? What is the actual behavior of the app? In certain, you know, points of time?

There's really no easy way to do that. I'm a visual person, I love diagrams. People have many different ways of communicating this in human terms, but in computer terms. You basically are stuck reading the code. And that's why when you onboard a developer, it takes weeks and weeks in order to, you know, get them to be familiar with the code base. And I'm sure you've all experienced this. Like, I don't think that there's anyone who, has joined the company and was able to be immediately productive. In the first hour that they were there. It usually takes a bit of time to sitting back, observing people, and then, you know, you could finally jump in and do stuff. And so the reason, like I said that I think that this is because, uh. When we determine like, what the features and the use cases of the app are, it all starts at the human level. We have project managers and designers and other stakeholders who determine here's how I want the app to behave.

So we draw diagrams, we craft specifications, we write user stories to explain this, and then we hand it over to a developer. And so these specifications get converted over to code. And so now this code, is in a computer-friendly format, and so the specifications are in a developer friendly format. But notice how you're sort of playing a game of telephone here. Because there's no direct connection between what we want to happen in the app and how it actually behaves in the application. There's, you know, leaky, like just you, you could call leaky specifications where the code does not 100 adhere to the specifications. And also typically what happens is, you know, we have hotfixes, new features, etc. So the code changes, but the specifications don't change. So if we need to refactor or redo the app, then the code is out of date with the specification. And also if the specifications change, then there's still that, you.

Know that lag between changing the code, according to the change specifications, and we know that the code is not going to be up to date. Because, I mean, honestly, there's a disconnect between the two right now. So, you know, ideally, what we have is just humans talking directly to computers, and, with this, the specifications are the code. And this means that we need to craft something that can be understandable by both, project managers, designers, developers, and, something that we could visually see and understand and have those map directly to, you know, to what the computer understands and how the computer can actually execute the application exactly according to the behaviors that we want. So how can we get there? Or how do we bridge the gap between the ideas that we have in our head and we try to express in human terms and code? So, to answer this, we can actually just rephrase this question by saying, how do we bridge the gap between formalized ideas? And now that we have formalized ideas, how do we communicate those formalized ideas? So, just like I was saying before, we're combining specifications and code, and really presenting and creating one thing that can be used both at design time and computer time.

So, yeah, that's, that's pretty much what I want to talk about today. So the building blocks for this are two things. We have events, and so events are really anything that can happen in your application, in your system, in your software. Whether it originates from human interaction or something like. You know, when you get, when you make a fetch request, you get some data back and then things change. Or other signals that might come in and behaviors. So this is how the system should React due to those events.

Play from 3:00

So, and that gets you know into what a state machine is like, if you're sleeping and the alarm goes off, that's an event now you're awake. And so if you're awake and the alarm goes off, you're like, ignoring it, or, you know, wanting to turn it off or something. But you're going to behave differently than, when you're asleep, rather than when you're awake to that same event. And so virtually all applications can be described. By these two things, the events, which is what can happen to it, and the behaviors, which is the reaction to those events. And I refer to behaviors as states interchangeably. I know state is a bit of an overloaded term, but when we talk about state, we're talking about behavior, like the finite states. So just keep that in mind. When we're talking about state machines, they're referring to behaviors. All right? So, one way that we could actually, like, represent these in human terms, which is actually pretty common, with developers and non-developers.

So, like, are these? Given when? Then? Statements you might have heard them as, like, you know, behavioral programming, or behavioral testing, or cucumber or Irkin statements. Where it's given some precondition when some action happens, then a post condition should occur. So, for example, like the example I said before, when I'm tired and I drink coffee or the alarm goes off, like, you know, if I'm sleeping, then I'm awake. And so, you know? This forms the basis of a user story, it forms the basis of the test. But this can also form the basis of, how we actually specify and code our applications, and um. You might notice that this is exactly a state machine. And so whenever you're writing user stories, or, you know, you have all these given when, then statements, in reality, you are creating a state machine. So, yeah, I hear a lot of people say, like, Oh, I'm not sure where to use the state machine in my app.

Here's a matter of fact you are already using state machines, and you're using them everywhere so that you don't realize it. But when you see this pattern, that is specifying a part of a state machine, and you probably have these all over your application. And so, one common way that we represent these, you know, state machines, or, you know, visual formalisms, are, user flows and flowcharts. Where we, you know. A designer might present you with a screen and say, when the user clicks this or taps this, or, you know, does this? Then you're in this different screen and that screen might have a different interface, which reflects that it could have different behaviors. The user can now do something different. In that screen, but a more strictly formal visual is, or visual formalism.

Play from 9:00

Sorry, I got those words mixed up. Are sequence diagrams, and diagrams are also really useful for describing how different parts of the system can communicate with each other. So one example I'd like to give is, you know, if you're at a cafe and you, tell the barista, Hey, I want a coffee? And the barista will tell the, the person who makes a coffee. So all right, maybe this is the cashier, that's a barista, and so the cashier will say, okay, it costs this much, then they will pay that much. And then when they get a receipt at the same time, the barista is making the coffee, and so the barista notifies the cashier, and the cashier returns, with a coffee. Now this is a bit of a friendly example, but a more practical example would be, oh, you have many things communicating with each other in Oakland. If you've ever tried to figure out Oauth like without having some sort of visual diagram like, you might have gone almost crazy.

Just because there's so many different things that you have to keep track of, and so many edge cases. Where you have a client, you have an off clients, off server, and you know, maybe some other remote server like off zero or something else like that. And there's just events going back and forth, and there's no guarantee that one will respond with an event that's, you know, you expect. So, yeah, sequence diagrams really useful for just showing that different interaction between different parts of the system. And then we have state machines and statecharts, which are my favorite visual formalism. And I'll describe what state machines and statecharts are in a minute if you aren't aware. But, state machines have been around since, you know, the early 1900s, with, Moore and Miele, and even before then. Um. And statecharts were invented in 1989 as an improvement on top of state machines. And so, if you haven't guessed, this talk is about visual formalisms.

And so one of the things that appealed to me most about using state machines in statecharts is that they're visual formalisms. And what? I mean, by that is, visual formalisms are things that, are visually exact, so it's basically like a visual programming language. It's not just like drawing something up in Excalibur and handing it to a developer and being like, Hey, this is sort of what I want this to do. This is more like the way you draw. These diagrams are, they have two purposes number one a human can follow them and understand the logic just by looking at it. You know, you would follow the arrows and be like, okay, when this happens, now we're in this state, and when this happens, we go from this state to that state.

Play from 12:00

And so they could be, used as executable diagrams, so they could basically be code. Unfortunately, that's not the typical way that we write code. But, that's basically what visual formalisms are. So, there's a really cool example that I want to show you, and it's this, stopwatch example by Andy Jakubowski. Hopefully, I'm pronouncing that name, right? And what's interesting about this example is that this I, I don't know if you know, maybe some of you are old enough to remember the citizen watch is before my time, but maybe not before yours, but this is an actual working digital watch. And we could, you know, just go between the modes like, I'm turning the light on and off. And you know, I could switch this to date. And maybe click here and remove the battery, which turns it off, insert the battery. And just do a whole bunch of different things to the watch I could change, like the chime. And this is really cool because, you know, I have seen these watches in person, and it is very much like a, a real watch.

And so what's? What's really the most interesting about this is that this watch is based on this statechart, which, of course, the watch has many features. So, this diagram is going to be a little complicated, but if you zoom into each of the parts, you could get an understanding of how each different part works. For example, the stopwatch, of course, we start in zero, and then, you know, we could turn it on and off. And so. The display, we could also turn it to, you know, regular, or the lap view, and of course, the alarms as well. So, you know, we have alarm one, alarm two, both alarms, so I guess this comes with two alarms. And, we see that we have different regions, so we have an alarm for alarm one. It could either be disabled or enabled. So, it's really cool that you could actually understand the different features of the watch just by reading this diagram, and this is cool too.

Like we could go between seconds, one minute, ten minute, hour, like, just to update the, the time. And I wish I had these for, you know, my microwave and stove. Whenever daylight savings time hits. Because I always have no idea how to up to the update, those to the correct time. But no, what? What's seriously? The coolest part about this to me is that this diagram was in Harold's original paper, and this paper was written in 1989, which is, I think, more than 30 years ago. If my math is correct. And so this exact statechart was used to power this watch. So imagine creating a visual formalism for logic that you could just code this directly, as is. You know, you have the entire specification here, and it still works exactly the same after 30 years. The only difference is now we're using it in some front-end framework instead of, you know, instead of in a physical watch. I mean, the logic is completely abstracted from the, the UI.

So I thought that was pretty cool, but yeah, as always, as I was saying in David Harel's own words, uh. Visual formalisms are diagrammatic and intuitive, yet mathematically rigorous languages, so the diagrammatic and intuitive part. This is most important for the people actually creating this logic, the developers, the designers, the project managers, and the mathematically rigorous part that's most important for the computer. So we're creating, we're, you know, building something that can be used both to communicate logic and used for coding. And so now, using these visual formalisms, we no longer have a disconnect between the logic we want to represent and how we actually implemented in the code. And so that's what I find coolest about visual formalisms. And so. Typically, in applications, we don't really code like this, we sort of code in a different way. We have our logic spread out between event handlers and callbacks, and, you know, just ad hoc logic all over the place.

And there's really no clear sense of organization. To get an idea of any of the features that are in the app, we have to really search around and see. Like, oh, okay, this function calls that one, which calls this other one, and you just sort of try to piece it together in our brain. And unfortunately, most of the logic lives in the brain of the developer who created it. And the expiry date for that is like two weeks or so, because that developer themselves will forget, you know, that logic. Unless they have it clearly written down. Which, let's admit, you know, most of us don't.

Play from 15:00

So, one way to organize this is by using a reducer, and so what's cool about reducers is that now all of the logic is centralized. And when events come in, the reducer can React those events and update. The. You know, different parts of the states based on that event. But notice how, like all of this date is still grouped together. There's no, distinction between the different behaviors of the app, it's just all data, you know, mixed together. And so that's where state machines come in handy. State machines sort of take reducers to the next level, and you could think of a state machine as a reducer. By the reducer. With a little bit, you know, stricter rules, and it's really meant to, like, categorize the different behaviors of the application. So, now we have different parts of data, which can change based on events, and, so, you know, you could just imagine this as different behaviors.

Uh. For example, fetching, you might be in an idle state, then a loading state and a success state. And so when you get an event that comes in, that might do something different in a different state. So if you get a fetch event in the idle state, that should start loading, and if you get the same fetch event in the loading state, you shouldn't react to it. So that's what I mean by different behaviors, um. So state machines are an improvement on these reducers, where you just shove data and logic in, you know, wherever you want. But state machines aren't without their problems. With this kind of flat structure, you could have many, many different states, and the more states you have, the more transitions you have. And this is, this just results in a complementarial explosion of states. And so that's why statecharts were invented. That let you really group these states more logically.

And, you know, just help you consolidate different behaviors and group them in a more natural way. And so that's what statecharts are about. And of course, there's also, like, if we zoom out a bit, there's the actor model, which again, the visual formalism for this is the sequence diagram in which each actor represents or the behavior of each actor is represented by a state machine, and actors can communicate with each other. But this is a whole other talk. So, now, you, you might know that. I created XState, and X8 is a way of implementing these state machines and statecharts in applications. And so we have an example state machine here. Where you know, we're in the idle states and you can see this is the initial state marker. And when a search event happens, now we're in the searching state, so like I said before, if a search event happens in the searching state, this state doesn't handle it.

You see that there's no transitions going out of searching, so we're already preventing impossible states. And trust me, I go into applications where if there's a button and it's not disabled, I'm going to click it a lot and just see what happens. Or you might have run into pages where it's like, please don't refresh this page. And that's because they don't have a proper state machine, where it's like, Hey, we're going to resubmit your request if you refresh this page. Yeah, it just gets a little bit silly. But anyway, I created XState in order to make it a lot easier to create these state machines and states charts. And so the way that this state machine looks in X8 is, is like this. So it's basically a big object we have create machine from XState. We specify the initial state, which is idle right over here, and then we have our states which is idle.

Searching success and failure, so in each of these states we specify the transition. So on search, go to the searching state, and then when we're in the searching state, on resolve, go to success, on rejects, go to failure. And so, hopefully you could see from this how? Like, if you need to implement a wizard form or something like that. Or even just a complex loader where you have to fetch data one after another. That this could be useful because you're basically creating a chain or a directed graph of behaviors, and you're just specifying on blah, you know, go to the states or do some sort of action. So, yeah, and so these machines, you know, are you? You could use them basically as a peer reducer, just by using the transition function and or, sorry, the transition method. And so that's going to just return the next state.

So you could use this within a Redux context. Or useReducer. If you're using React, it basically spits out a fancy reducer for you to use wherever you want.

Play from 20:00

But more practically, we have interpret where you pass the machine in there, which represents the behavior of some part of your application. And then you, you send, start. And so this will start the service and make it available to, send events to. So, for example, if I send it a search, then it's going to change the state. It might execute actions, invoke services, you know, do other things, and you could send it events from anywhere. So if you've used Redux or NGRX or VUX before, this is going to all feel really familiar. But now you have a state machine backing this. And so, a lot of you might be thinking like, Okay, what do I need a fancier state management tool for? Like, what other benefits does this bring me? And, the main benefit is that this isn't just state management, it's state orchestration as well. And, we have a visual formalism which we could use to collaborate with other people.

So I want to demonstrate this, in this sample app that I have over here, uh. This is a sample checkout app. I love LeGo, so I just built it based on that. And if you've ever been on the LeGo checkouts, then this is going to look really familiar to you. But it's also interesting that the LeGo checkout flow uses XState itself, so if you've been on that flow, you've been using X8 without knowing it. So let me just show you how this app works real quick. We could enter a VIP code here, we could check out securely, or we could pay via PayPal, so I'm just going to check out securely. Click a shipping address, select a shipping method, and then enter an email gmail.com. That's my actual email, and this is not my number. But yeah, then I, you know, pick a payment method, agree to the terms and conditions, place order, and then I have a confirmation over there.

So this is your typical wizard form, which does have different flows. So if I click pay via PayPal, then I don't need to enter all the other information. And it just takes me straight to the, you know, second to last step. And so the machine for this looks like this. We have a checkout machine where we have this extra data over here shipping address, method, email, mobile. Just anything that you would put in an object in, you know, Redux, or whatever other C management tool you're using. And then we have the different states here, we have cart, shipping, contact, payments and confirmation. And just like I showed you with the simple search example, we have transitions over here. So if I click checkout, it's going to take me to shipping, if I click PayPal, it's going to take me to payment. So it's going to skip a few steps because we don't need, you know, to do that. Then we have, you know, events here for actually updating the data or the extended states, such as the shipping address or the shipping method.

And then we can click next and we also have validation over here. So there's such a thing as guarded transitions where, you know, if we this valid shipping, you know, we could just say we need a shipping address. Obviously, you can make this as complex as you want, and it goes all the way. To confirmation at the very end. And we could, you know, even invoke some async fetching, you know, to actually make that payment, see if it succeeds or fails. But this is an object, this isn't really a visual way of seeing this, it is nice that it's an object. And I could, you know, collapse things, see the different states, see the different transitions. But, like I said, the one of the primary benefits of using state machines is that it's visualizable. So I'm just going to uncomment this just to demonstrate, and this is going to open this state machine over here.

So, this is a visualization of the actual app. And so we could see without me having to go through the object and explain just all the different things that could happen. So I can see. We go from cards to shipping, to contacts, payments and confirmation. But I also see that if I click PayPal, we're skipping these two steps and we go to payments. And so this is something that you could show a designer, project manager and just give them a higher level understanding of the current application. Logic, which I think is really useful. And if we interact with this app, like, let me just click checkout securely, then you can see that it actually changes. State over here, and so now we're, you know, at the shipping address, select shipping method. But what's cool about this is that I could also manipulate it here and so now it changed to the contact state, and it changed over here too. So it's sort of a bi-directional thing.

And we're working on like a BS code extension, chrome Dev tools for this, so that you could actually have this side by side. But, you know, it's still pretty useful to see all this stuff. So having these, you know, this logic expressed in this state machine is, not only useful for visualization. But now, I mean, you're essentially creating a directed graph of your application logic. You know everything that can happen in every state, and with directed graphs, there's so much you could do, like we could generate paths, from one states to the other. And so that's actually what I did over here, so if I uncomment this, I have something called. Oops, something called checkout steps, and so what checkout steps does is we get all of the paths, that fulfill, like you know, certain criteria. So I'll actually show you over here. We have find scenario where it matches the predicate, and so my scenario is that we want to find some sort of path. That goes to the confirmation state and actually has a shipping address specified.

And so this these are actually auto-generated from the descriptions that I put in here in the machine, so you see, I have description shopping cart, I have a description. Even for each of the transitions, like entering VIP code. And so when we piece all of those together, we get these auto-generated steps that you could even add to, like a guided tutorial or documentation or something like that. And so let's say that we change this logic a bit and say we don't care about a shipping address. We just, you know, want to reach the confirmation page. The current logic is it finds the shortest path. So if I save here, it's going to say, Okay, yeah. All you have to do is click pay via PayPal, agree the terms and conditions and your order is confirmed. So, yeah, you could take this even further. And, because of the way that I created this, we could pass each state into this app.

And that's exactly what I'm doing here, so I'll just show you, in checkout states, we're basically rendering the checkout, at each different states in which we, so, um. Each of these paths are just a sequence of events that happen. And so, the cool thing I'm doing here is that I'm replaying parts of those events. So, for example, if I have 10 events, then I'm going to render the view at one event. Then as if we did two events, then as if we did three events, etc. And the result is this. We have a view that follows this, these steps, and so we see it goes here. Then we're at shipping address, let's say we pick one. Now we have contact information, then we enter some details, then payments, and so we could see every step of the process automatically generated. And this pretty much comes for free because we're.

Using a state machine. And we have a much more, formalized way of, specifying our application logic than if we were to use a plane reducer. And even if we were to use, like, just random logic everywhere, so, yeah, like I was saying before, this is, the distinction between, like, using something like XState and using state management libraries is. Now we're getting into the category of state orchestration. And the main difference between that is that state management provides you a convenient place to hold your. Your application states and data state orchestration actually is in charge of, you know, orchestrating between the different behaviors in your application. So, for example, when you use something like Redux or UX or something, it doesn't know the difference between is loading and is not loading. It's just going to think, Okay, I send you an event, you give me some data back, and that's the data that I hold. With XState, you make those different behaviors explicit, you say there is a loading state, there is a success state, and the application behaves differently in each of those states.

So, yeah, the uh. Currently, there's like a lot of modules for XState, we have support for reacts, view and spelt. If you're using Angular for some reason, X8 just works with Angular. We made it so that observables work fine with it.

Play from 25:00

But uh. We also have things like FSM, so if you don't want to use full XState, you could use FSM. Which is just flat state machines, or it stands for finite state machines, but f could also stand for flat. We have XD test, which is, allowing you to generate these, you know, the shortest or the simplest paths throughout your entire application and generate tests based on that. X8 graph, which you actually saw in the demo, allows you to, generate those paths, and XA test uses X8 graph and also X8. Inspect, which allows you to, to visually inspect your application and see it, you know, rendered live. We do have some future modules coming up, some things that we're excited about creating. Our our primary goal right now is working on the various daily tooling, but we have, plans, just creating. A parser for X8, which is going to be used in the VS code extension. Things like Xa form rather query like just add-ons that make using XState a lot more useful for everyday applications.

So I also want to mention that we have a that new visualizer that you saw. You could access it at Stately..ai Fizz. You could even save your machines and share them in the registry, and so you could see other people's machines, search for them. And yeah, there's a huge collection right now of different machines that people created. If you want to get inspired, and just, yeah, see what other people are creating. And something that we are working on right now and are going to be opening up for, early closed beta users soon is the Stately editor. So all of this, you know, this machine and everything, I mean, coding it up, like, you know, that's something that you could do. I know a lot of people do prefer code, but it is nice to also visually code it. And what's nicer is the ability to go both ways.

To have a visual representation of it, and to also, you know, edit it visually as well by dragging and dropping, and, you know, clicking and renaming stuff. So, this is something huge that we're working on and I think, late January we're going to, release it. But if you want to be part of, like, the early beta testers, then just let me know. Especially if you're using X8, we'd love to, you know, get your hands on it and get some early feedback. But yeah, so overall, the current state of collaboration is that, you know, we have sort of a handoff process between design and development and implementation. And, you know, there's been some improvements on this. Like, we could write documentation, we could create diagrams, and even better yet, we could create these diagrams from code. But there's it's still lossy, like, you know, when we, when we create these, you know, these specifications. It's very easy for things to go out of dates.

And so that's why I feel like the future is the like. Developers using, these low code tools and creating these executable diagrams so that they could. Express complex logic in a visual way so that it's more understandable to the rest of their team. And, you know, also, you have the benefit of having the logic be more robust and easily testable. And, you know, resilient against impossible states and something that everyone can contribute to. So, yeah, basically. Our goal is to make your code do more, and that's exactly what we're trying to do with all of our tooling.

Play from 35:00

So thank you Nordev for having me. And there's some links for you. We are at Stately..ai, and also, we're open source, so Stately AI slash XState this is the XD repo. The visualizer that you saw today is also completely open source, so you could see it at Stately AI Slash XD is. Uh. And we also have a really friendly and active community at Discord..gg XState, so please join us. I know a couple of you on the call are members of the Discord, so thank you for being there and we hope to see more of you there. So thanks for having me. Oops, it's my Twitter, thanks David. That was, yeah, fascinating, really interesting. Really. Yeah, really curious to see. So, yeah, that's it. Still a little bit. One of my questions were going to be about the bidirectional, being able to use it both ways. But you've, you've already answered that, right at the end, the, the editor looks, yeah, fascinating, fascinating. We've had a question in from Aaron on the YouTube, thanks Aaron.

David, do you have any guidance on when nested machines should be refactored to use? Actors? That's a good, that's a good question. So, yeah. Actors are like, just sort of one of the more advanced parts of XC. But they're also really useful in terms of separating behavior. So that you have different parts, representing different responsibilities, and each of those responsibilities just passing messages sorry back and forth between each other. So basically it's just getting a good feel for. When your machine gets too big and you could start to isolate parts of that machine to different machines, or even different reducers. Or, you know, callbacks. If you don't want to go full seat machine quite yet, that's a good opportunity to just to just separate them into. Actors so, what I do want to say is, don't be afraid of actors and the actor model. It's really less complicated than you might think.

In fact, I think, it's probably simpler than trying to understand all the different parts of state machines. So I do encourage you to, yeah, use actors when you can. Yeah, it was one of the observations I made was just towards the end, even that kind of, the wizard, the, the checkout was it? It got quite unwieldy to potentially get your head around, but pop it in one of those editors or the visualizer, and you can get your head around it quite quickly. The the idea that you potentially could grab. Grab a little module of logic from the from Stately library as well and just dump it in. As an actor and then start instructing it, you've got a module that. Yeah, it's, yeah, awesome. Yeah, I'm jealous. So Aaron's just backing up the. The Discord is fantastic. So yeah, get on the discord. Any questions? Obviously. Yeah, get loads of support there. And just thanks from everyone coming in on the YouTube, so yeah, awesome, yeah again.

Well, if there aren't any more questions from the YouTube, we're going to go, private and have the rest of our Q A in the zoom. Cool. Oh, you could have, Aaron says. You could have one, act of fetching data and another taking that data. Just do something with it. Yeah, fascinating that, yeah, I'd say, the modularity of it, as always, yeah, so I. I just want to point out that the hardest part about, like, using steam machines and stage arts isn't just like learning the concepts. I mean, that there's a lot of concepts to learn. But once you get your head around it, it's, you know, pretty intuitive. But it's more like just the actual modeling of, you know, different states and actors. So it's sort of like running a company. Like, if you're like, Oh, you know what? I'm going to delegate this test, that person, that person is going to be a manager, this person. We're also going to hire all these other people to do stuff.

And like, coordinating between that many people gets really difficult. So that's why, you know, sometimes people. Say, oh, I'm going to use actors for everything, and then it just becomes really complicated to organize that. And, yeah, so it. It's honestly sort of a, an art. Just making more of these machines and getting used to, like, all right, what are the right patterns? You know, for modeling these different things? Yeah, yeah, awesome. Stop thinking about it, supposed to think about all right. Well, yeah, thanks for joining us on the YouTube. Like and subscribe and all that usual cliche YouTube stuff. See you later.

Play from 39:00