# RRU 069: The State Machines in React

Canonical: https://davidk.dev/talks/rru-069-the-state-machines-in-react/
Video: https://www.youtube.com/watch?v=8n_Z23qbAHU
Speaker: David Khourshid (@DavidKPiano), creator of XState
Type: Podcast · Event: React Round Up 069 (Top End Devs) · Year: 2019 · Duration: 54:55 · Views: 1162 (as of 2026-10-19)
Topics: State machines, React, Statecharts

## Summary
Whether you know it or not, you're using state machines every day in your programming. One of the most interesting effects of thinking about your application as state machines, or at least a part of your application of the state machine, is that.

## Key takeaways (quoted from the transcript)
- Whether you know it or not, you're using state machines every day in your programming. (12:00)
- One of the most interesting effects of thinking about your application as state machines, or at least a part of your application of the state machine, is that. (16:00)
- Jakob Beard is a developer who has created Sion as a project which interprets what's called SC XML, and so XML format for describing steam machines. (33:00)
- I think my first exposure to state machines was in college, and I never really touched him after that. (41:00)
- Either writing new features, which even if a feature seems simple, like add a button there, you're like, Oh well, I have to so many things in so many different screens or fixing bugs. (46:00)

## Chapters
- 0:00 Introduction
- 9:00 I think there's a big difference between the sort of imperative…
- 18:00 You wonder why the house takes so long to build and…
- 21:00 If you, if you're just like…
- 27:00 Sentry provides a terrific interface for keeping track of what's going…
- 31:00 I was working with this medical company and we were doing…
- 33:00 You have so many tools for, you know…
- 36:00 For that reason is because they have the declarative notion of…
- 43:00 I think we need, like that weird healer…
- 45:00 Either writing new features, which even if a feature seems simple…
- 50:00 Without a lot of the hassling overhead…

## Transcript
[0:00] Hello everybody and welcome to another episode of React round. Oh, I'm your host today Dave Selya, and today on the panel we have Lucas Hache. Hello everybody and Thomas, A lot, hello, I don't have a ball. And joining us as a guest today is David Corsi's Hi, nice to be here. He's maybe better known as @DavidKPiano on Twitter, and Dave is the author of a library called XState. And also a bunch of really amazing code pens.

[0:00] The show David, glad to have you me. Hey folks, I just want to let you know quickly about Net Liffe. I Net Lafay is a really cool system for posting what are traditionally known as static sites. However, the real benefit that I've been finding is that I don't have to mess with a back-end. I can just set things up. I build the website out. I've been using a system called 11 DJ S and you just deploy it and then anything that you have that you want to do, you can do on the front end.

[0:00] So if you want to pull in some kind of database with Firebase or something else, if you want to collect form data. That Left-Eye provides all kinds of services that make it easy to do all that stuff. If you're trying to do server lists, they have a really, really neat server list setup. That will allow you to deploy your websites without having to deploy a back-end. And it will do some of the work for you.

[1:00] I just, I just love it. So if you're looking for a way that you can actually deploy a website that only has front-end technology in. It gives you all the tools that you typically need for the backend without having to actually program the backend. Then give them a try go check them out at Nullify. Calm yourself in your Beckert. Sure, so. I've been a web developer, software engineer, everyone in college for the last seven years.

[1:00] I currently work at Microsoft, where I've been working there for a little over two years, and previously I was just jumping around startups. I started off learning PHP, but my passion has always been the more fronting side of things. So I eventually moved on to JavaScript, CSS and just exploring that landscape and see what kind of damage I. Could do I also play piano? Hence? MAYA Oh, how did you get into software development?

[2:00] Was it like three-year versity or yourself talker? Sort of? So. The interesting thing is that I actually went to college about not things like 10, 12 years ago or however many years ago. Can't math right now. But I studied, I studied piano performance in college. Yeah, I was always interested in computers, but I was more interested in piano, especially because, you know, I went. It's University for piano, but there was a internal music technology class where the final project of the class was.

[2:00] You have to make your own website and you have to use this program called iWeb. It was sort of this drag-and-drop web editor program that was only available on Macs. And I had a PC. And I really didn't want to make the trek to go to the computer lab at the University. So I thought to myself, how can I make this website myself on my computer? And so I started researching HTML, CSS and just threw something together.

[3:00] And when I presented my website to the class, they were like, you should really do this as a career. So that's pretty much, haha. It's funny. Sorry, so you did. You did a piano performance as an undergraduate? Yes, that's funny. It's not the first person that we have as a guest. It has like a music background. And I also, like, worked as a keyboard player professionally for years before being a software developer.

[3:00] So it's so. It's pretty amazing to see the pattern. Yeah, anything with a keyboard, huh? Just roads helps with your typing skills. I mean, yeah, yeah, I can say that my type of skills is probably like, my worst part is developer. Yeah, yeah, I hear you're supposed to use your pinkies occasionally, like, like, I guess how pretty, right? Yeah, that's funny, so, but so, David, I know that your code pen is amazing, and I saw a bunch of your posts about CSS and CSS animations.

[4:00] So is this the first? Like, are you? A lot of people that start with front-end programming? Some people start like from more like design background like CSS and HTML, but other people comes more from our from like backhand background start - usually with JavaScript and stuff how? Would you say, like, your started, you just start with the CSS side of things? So, actually, I started from the PHP side of things, like many other web developers who have around the same experience as me, we started like, just working on Wordpress templates and themes, and, you know, just making one-off websites here and there.

[4:00] And maybe working with some sort of back-end Mamie in PHP or C-sharp Net, or, you know, something like that. And I, I just got a lot more interested in the front-end landscape, but JavaScript was still pretty, pretty unfamiliar territory to me. Of course, I can make some simple stuff, and I was using jQuery for everything, but I eventually was like, number one JavaScript is really annoying in. It was back then, so I tried to do as many things in CSS and HTML only as I could.

[5:00] And so, yeah, yes, you'll see then a lot of my code pens. And in fact, we have a we have a show called the key Framers that airs every week on Mondays, or we can you spell that key frame? Errs. So frame dot RS is actually the website, but key Framers? It's me and Steven Shaw who works at code Pen, and we actually do a lot of these code Pen, HTML and CSS experiments with only a tiny hints of JavaScript.

[5:00] That's basically where I started I. I got really fed up at jQuery, as pretty much everyone - because jQuery quickly devolves into this very complex mess of code. That you have done well, or just start a new, you know, when you have a new project. So that's where I sort of tried to develop techniques for doing everything in just CSS and HTML. But eventually I learned that, you know JavaScript. When you know, properly planned out and modeled, it could actually be a you know.

[6:00] It could work in harmony with the declarative nature of each team LM CSS. So I sort of approached it the backwards way. I wasn't very good at Java scripts for the first few years of my development career. That's funny. I kind of had a similar background as, like, I was doing all front-end stuff, I really got into. CSS is, like it, a challenge. I, I hated all the JavaScript that I saw because it.

[6:00] Was just gnarly poorly managed. And it's interesting seeing, seeing somebody go through this. But with modern CSS, it's like, I guess my skills of blacks dang, right? But I mean, you would be surprised how much you could do with modern CSS nowadays. All the grid hacks that we had to do back in bootstrap days now is built into the language and supported in all modern browsers. We have Flex box now, our animations look nice because we have all these transform that we could do, and yeah, hardware accelerated with the browser and all the stuff.

[7:00] Mm-hmm, yeah. So looking at that, like your, your main like cold pan that you put on your on your website. Is the Huskie? Yes, this SS husky, yep, which is crazy. How long did it take? Like, how, how, how was the process? Like, what, where did the idea come from? Like, how did you come up with that? Was that like an exercise you put yourself like? So I, I typically like to look at dribbles and see, can I recreate this?

[8:00] And, of course, only the assassin. Before that, when I made a lot of pens, that followed that same sort of self-imposed challenge. I was in San Francisco, you know, at work one day and my coworker and I were, you know, just looking through a triple. And we saw this, you know, really awesome husky animation. And so she challenged me. She's like, I bet you can't do them just HTML, CSS in, like, so I, I.

[8:00] I went to the hotel room that night. I spent about, you know, two, three hours just, you know, busting it out. Because I. I've done similar code pens like that before in the way, like just the same techniques of trying to make the precise CSS shapes with the code pen. And also layering the HTML elements just right so that they mimic natural movements, like natural body parts or dog parts, I guess.

[9:00] And using SASS and HTML, I was able to make that animation that sort of blew up.

[9:00] And I'm surprised, like, wow, there's a lot of people sharing this, and I didn't know why. It was just like, it's just a dog handing me a dog. But it's funny sometimes, the things that once we've demystified something for ourselves and we. Fully understand. It kind of loses that mystique and it's not really impressive anymore. But for the few people who actually use stuff, make stuff, build stuff and share. It's so inspiring to people to kind of show this is what's possible with this technology.

[9:00] And that it kind of inspires people to learn and to grow and to do more so. Thank you for kind of inspiring the community to get out of our comfort zone and push forward. Yeah, and I think that's important because I have to say, and I, I could be wrong, or, you know, people might disagree. But I feel like one of the best ways to really learn JavaScript and learn how to craft like very well-organized, good, modular JavaScript is to stop using it.

[10:00] Try, and, honestly, try to as much as you can without JavaScript. When I was making the dog. And when I'm working on other, you know, complex user interfaces and animations, and trying to use this little JavaScript as possible. It forces you into a way of thinking, and that way of thinking is thinking about your dynamic at in terms of states. So even that dog like, there are certain states or poses that the dog is in, and so I'm simply using keyframes to animate between those poses, and so just like that dog is animated.

[10:00] That's the exact same sort of philosophy. That are dynamic apps working to where our apps can be in different states. And everything we do is simply transitioning from one state to another state. So how would you define a state? A state is a moment in time, and it's worth, like, a in abstract concept. But, for example, right now I'm hungry, that's a state, okay, and so that states can change, right? If I eat something, I'm no longer hungry.

[11:00] So that's a state transition. Set state hunger equals, oh yeah, except I would discourage using set state, but yeah, nothing, not on a human. So is that how you? You think about? Every time you're gonna solve a problem with software you think about, like, which states the does that problem have? How do you transition between them? Yeah, yeah, because the funny thing is that every single developer, all right, so someone they talk to developers about state machines, which is what this overall concept.

[11:00] Is they either say one of two things? They either say, I, I don't know what that is. Is that a new library or something? Or they say, yeah, I remember learning about that in college or university. Many, many years ago. I fell asleep in that class, it was the most boring class ever. Yeah, but they're important. And everything we do today, like every single one of our applications and every single line of code we have, right is a state machine.

[12:00] REG X is a state machine. The way your code is interpreted is a state machine. The way your computer works, in the way that networks work, are based on state machines. So whether you know it or not, you're using state machines every day in your programming. But the way we do, it is implicit, and that becomes hard to recognize. Like, which states are we in our application, in which events are allowed to cause a transition between different states?

[12:00] And and that's how you get buggy and messy code, and that's how you get, you know, things like impossible states where it shouldn't be in the states. Like, for example, if you see an error message in a success message at the same time, it sounds ridiculous, but I'm sure you've run into apps where that's happened. Yeah, this is, this should be impossible. Like, why is there an Arabic success? At the same time?

[13:00] Not yet not to talk about when it's a success and error and loading stage. Oh yeah, I've seen that. So another possible, you know, utility of this is being extracted. Us to get explicit about our view, our UI, and so thinking about, how can we be explicit about the states? And all of the different kind of poses that our app can be in and transitions between them. Cannot just be good for forcing us to think about it more clearly, but can be good about, like, onboarding new people.

[13:00] Communicating very clearly about exactly how the thing is working instead of hoping that we both have the same kind of mental model, of course. So I'm sure that you all are working on complex apps nowadays, right? There's, you know, some, well, there may be some side projects or something. Think to yourself, how easy is it for you to onboard? A new developer and say, this is how our app works. Mm-hm. How will you seize it?

[14:00] To say, like, Oh, the way that the user uses is they log in, but that login might fail. But if they log in, then it goes to this screen and it goes to that screen. You're probably imagining this right now, and if you're not using any sort of state machine solution, then you're probably thinking, okay. I'm jumping around so many different lines of code in so many different files, just to get them to understand where everything is.

[14:00] Because everything is just haphazardly wired together. Mm-hmm. And also showing code to a developer. I don't know if you've seen someone else's code. It's like, it's like a different toothbrush, right? You're most comfortable and familiar with your own toothbrush, and you don't really like sharing anyone else's toothbrush. Silly, because with code, right? But if instead you show a diagram, like what designers typically call a user flows, then it makes crystal clear.

[15:00] In a sense, you could instantly say, alright, we go from this date to that state when this event happens. And this is something even non-technical people like product managers or your CTO or designers can understand. I think it also depends on kind of people's learning styles, because some people learn best. By getting you know the precise step by step, you know, minute by second by second, step by step instructions. And can't and get lost when they're looking at the big picture, and like other people, need to see the big picture first.

[15:00] Because if they just get the step by step instructions or totally lost, that's me. Mm-hmm, yeah. I think there's a big difference between the sort of imperative thinking, but the step by step thing versus the staple like thinking in states. And they can be both in order to fully understand something back and forth. And if you think about it, like, especially with regard to, you know, state machines and how your app flow works.

[16:00] Estates would be, you know, of course, just specific statuses or modes in time that your app is in an events would transition between those states. So your imperative way of thinking of, like, alright, do this, then do that, then do that, that's just a series of events. Mm-hmm. Scribe it as such, so it still fits within this whole steam machine model. Yeah, the part that I think it's. One of the most interesting effects of thinking about your application as state machines, or at least a part of your application of the state machine, is that.

[16:00] Before touching code, you can, if you are describing our safe machine in whatever language or platform or tool that you choose, you are able to collaborate really, really, like, deeply with non developers to write, so this is for me, this is a huge win of working with, say, state machine lifetimes. Yeah, like designers and product people, they're looking at the thing with you and they and they are like, Okay, so this isn't, makes it makes sense that transition here does not exist, or there should be a transition from this to this.

[17:00] If you are able to bring this state machine to your code, that means that you just collaborated with really smart people that are not developers, right? So this is interesting, it is, it's interesting, and it seems innovative. But first of all, other industries, like other, you know, areas and tech, have been doing this for decades now. And also, if you think about it the way we develop nowadays, like just as a collective whole.

[18:00] I'm not saying everyone does this.

[18:00] Hopefully, not every developer does this, but it's worth like, asking a developer, can you build me a house? And they start, they grab a shovel and they start thinking, and then, and then you're like, actually Beveren needs to be bigger, and they're like, no problem. I will just dig around and move things and, you know, readjust things. You wonder why the house takes so long to build and why certain things are created.

[18:00] Let me show you the house. This is a wall, this is another wall. It's not the way you show a house. Lots of bricks gonna see, like there's some bricks here somewhere. It's over the TV, right? So for centuries, they knew that. Yeah, this is probably a pretty dumb way to build things. And so we have things called blueprints, where we have a blueprints, a schematic diagram, a model of how something is supposed to be built.

[18:00] And then we could, I'd array them that either using, you know? CAD software like design software, or, you know, pencil and paper or something like that. Once that model is finalized, then things are built. I'm always surprised to see it like just huge structures such as bridges and you know, just other like huge buildings where I'm. Like, they had to plan this and get everything exactly right. Otherwise, you know it, like highways and stuff, otherwise it, it would just fall apart.

[19:00] That's it. Yeah, yeah, the checklist manifesto, because they go into that a ton in that book, like a guy's a, like a surgeon. He's trying to learn how to get better at teamwork in hospitals and learning from the construction industry. Because their success rate is through the through the roof and there, and buildings together, skyscrapers willy-nilly like that with, you know, they're not falling over, everybody's getting stuff done, everybody's getting paid, nobody's getting hurt.

[20:00] Well, relatively, yeah, yeah. And so that's why I think it's important that, like, we should learn from these other industries, like not just tech industries, even though there's so many things we could learn from. For example, the gaming in, you know, game tech and automotive engineering, embedded electronics especially. Yeah, all the hardware stuff, I mean, that's the difference between hardware and software. Like, you've got a nail it the first time, because, yeah, it's gonna cost you thousands of dollars extra.

[20:00] If you have to, like, recreate these circuit boards over and over again. Yeah, I signing it to the moon, maybe, maybe right in Java, yeah. And so that's one of the thing I talked about in my presentations. Is that sending the Mars Rover, that's a I think, was like a 200 billion dollar project. It wasn't in same amount of money. And they had one shot. The software had to work perfectly in order to, you know, fire the boosters at the right moment.

[20:00] To me, just new landing. And and they had to predict every single possible thing that could go wrong.

[21:00] Yeah, right, otherwise things our mistake. And we can afford a software developers to make mistakes, which is why we just start programming without really considering modeling our software properly. Nobody, yeah, holding us accountable. Do you think? It's also like an effect of the waterfall versus agile like mindset, because I think that there was a big cultural shift. Like, the waterfall was like, Waterfall is really bad, because it's like months of planning.

[21:00] And then when software, it gets written, it's not what we needed. So projects fail. That's why we need to do a giant that is like, let's create like, deliverable things from day one. So do you think that maybe like we went too far? Like, I think that people? We tend to think that after we create, called creating code and changing code is almost like zero costs, but it's not. It seems to me that's what I like to say to people, it's not.

[22:00] I don't want to back to two months of planning, but I want to have at least like two hours of planning someday, right? Like, and so, if you're working in an agile environment and you don't have, you know, these proper planning sessions, then. Sure, you're going to move fast and break things, but with the emphasis on breaking things. And then you're going to have your team spending a week where the goals of the Sprint's are less on features and more on fixing bugs.

[22:00] But thankfully, your team will be like, Wow. I was really productive this week because I fixed a lot of bugs that I created in the last few. Spritz it, but that's not productive at all or nothing. Yeah, I'm gonna see us right now. Fixing bugs is unproductive, completely unproductive. Preventing bugs, that's what's productive. Yeah, and some things are really, really, really difficult to change. Like, nothing is more permanent than a bad interface in a company.

[23:00] Like if you, if you're just like, let's just do this interface this way. And then we figure out loud to do better in the future. Then, like, five other systems are consuming your interface, that's it, it's, that's your interface. You're going to be married for months, yeah, for years. I think it's if it's a bad interface. It's gonna. It's gonna haunt your dreams, like for months and years, anything. They're able to deprecate.

[23:00] Prototype thing. Prototypes are a myth, right? Like whenever you start something off, you're like, Oh, this is a throwaway, right? Like, kind of works. So that's why in React is especially like when I program and React. Focusing a lot on the state machine approach allows you to. I know this word sauce. Around a lot. But it allows you to decouple the logic from your user interface in, of course, you're going to have, you know, logic tied to user interface.

[23:00] Elements. Such as when this button is clicks, then do this, but it becomes less of when this button is clicked. Fire this action into the side effect and also load this data, and it more becomes when any user interface elements is interacted with Sinan events. That's it else to send an event. One my demos with XState was to create, of course, a to do a me see, and so I experimented with.

[24:00] Alright, let's let's do this completely using state machines. So, of course, I had that proof-of-concept working and I had to do MBC React. You know, it looks like all the other ones, but what was awesome was there was someone I, I forgot who it was. But they took my exact code and they ported it to Spelt, and they said I didn't need to change a line of code. In the machines, I just use the machines.

[24:00] All the logic was the same, and I just rewrote, rewired the user interface, actions, and like, that's the way it should be. And so I'm thinking longer term in the future, like going further in reusing business logic. Tinnie Swift or Kotlin or unit Reacts needed if you want to stay with JavaScript other languages. The the third horseman of Reactor React started with, like, we have all these problems. Let's let's make one thing composable, just you.

[25:00] I will figure out everything else laid out later. And then with books, we got okay. Now let's get composable with side effects and all the all the life cycle stuff now that's composable. - this feels like the next level of composability is being very intentional. Extracting the state machine out because I've seen rights, I mean, we've all seen kind of state down in a million different ways. But it's all it's going after developer experience or being more intentional with this now, the other thing.

[25:00] But right? It seems like there are too many conflated concepts that need to be extracted out and kind of dealt with separately. So we need to be intentional about dealing with those concepts separate from the other concepts, right? Yeah, and so it's an interesting. Point you made about the conflated concepts. Because I think that every state management library that we have and React, especially I, that there's a new one coming out every week.

[26:00] They, they're all partial state machines, like once you learn what's the machines are, you realize that they partially implement them. And so I'm not trying to push my own library, I'm just trying to say, like, no. For instance, think about, you know it, in terms like, when I see a counterexample and I see like, it directly manipulating state. Like, Oh, yeah, just had one. Immediately I start thinking of the edge cases.

[26:00] It's like, what if you want a max value? What if you want some other thing to increment the count, like you want the timer also incrementing the count? Then you have to copy and paste that code. Or, you know what, if you want some other business logic for you, for example, you could only increments once every second.

[27:00] Something like that, yeah, where do those rules? Live exam? And as a what ends up happening is they live in our event handlers, all throughout our app. So some of the simplest changes that you could make to improve your app and sort of think in this more state machine mindset is. Look at your event handlers and say, like, are they doing anything extra than dispatching an event? And if they are, you might be doing too much in your event handlers.

[27:00] This episode is sponsored by Sentry do. Recently, I came across a great tool for tracking and monitoring problems of my apps. Then I asked them if they wanted to sponsor the show and allow me to share my experience with you. Sentry provides a terrific interface for keeping track of what's going on with my app. It also tracks releases, so I can tell if what I deployed makes things better or worse. They give you full stack traces and as much information as possible about the situation when the error occurred to help you track down the errors.

[27:00] Plus, one thing I love. You can customize the context provided by Sentry, so if you're looking for specific information about the request, you can provide it. It automatically scrubs passwords and secure information, and you can customize the scrubbing as well. Finally, it has a user feedback system. Built in that, you can use to get information from your users. Oh, and I also love that they support open source to the point where they actually open source.

[28:00] Sentry if you want to sell post-it, use the code Dev chat at Sentry Daioh to get two months free on Sentries small plan. That's code Dev chat at Sentry IO. So I think we did not mention it's like, we're actually now talking about your library, called XState. It's a framework agnostic library. Yes, it already has like adapters to the most popular frameworks. And that's the way you work with it, right? You first create like a Jason, which is a configuration of your state machine, where you configure everything you have.

[28:00] Like a great visualizer. They can just like, copy and paste it there. And then you can look at and you can start playing with firing events and see, like, what happens to the sake machine? That's the part which, which I really think is great, because that's the part where you don't need to. You works to collaborating with whoever have domain knowledge of that product, of that business, like you, you can. Everybody can sit together like in a computer and talk about how the system works.

[29:00] What are the even more basics of? Like, where does this go? It is like, so, imagine I have just a like a vanilla React like create React thing. I'm using, you know, maybe I through Redux in there, because I don't know what, you know, what I'm supposed to do. So there's, I just hear, Okay, there's this thing called XState, what would I use it for, and what would I remove from my app to replace with this?

[29:00] Is this directly competing with something? Is this like Redox with a different name? Like, it's no, it's not, but like, I honestly use it, however you want to use it, and that's why I made sure. Like these, deep machine itself is just a transition function, it's a pure function, and so, of course, you could use that in your Redux reducers. All you do is you tell it what's the current state, what event just happened, and it spits out the next state for you.

[30:00] It does, but this is not competing with Redux. This is like, I'm, this is sort of. Leap with it, although people have replaced Redux entirely with it, but we won't go into that. So that the machine part Tier function, you could also have it execute effects into all of that. And so would be using an interpreter. And so then it just becomes an event emitter. You could send an events, you could listen for state changes, that's it.

[30:00] And so it's really easy to integrate into, you know, any apps, and that's why adapters are actually pretty slim. So, for example, I have used machine hooks for reacts, where you could just pass the machine into used machine and you could use it just like a reducer. The only other, well, not the only, but another benefit it gives you is it actually executes side-effects for you the side-effects you specify in your state machine for view.

[31:00] People just stick it right in view and they subscribe to state changes and update their data model, you know, when state comes in.

[31:00] And then they just they have that send method so they can send events to it. And it actually feels very much like the UX, so people are people who use it in view. And so there was also recently an article that I tweeted that someone wrote about how to use X8 within an Angular application. So that's important thing, too, because since you could subscribe to a service, you could use it as an observable and Angular.

[31:00] Water bubbles, so there you go, that's amazing. I have a question like, what did inspire you to look at that? Like which other things inspired you? And what do you think? Like that? It's not X8 related, is doing like interesting work with state machines, like what languages or frameworks or whatever likes fired in the first place. So for the initial inspiration, it was actually one of my first jobs out of college was.

[32:00] I was working with this medical company and we were doing prescribing workflows for these very, very expensive specialty medication. Where you had to fill out forms. And I'm sure you've all had forms where it's like, show these fields that this is clicked, but if this is clicked and that's clicked, then show a different form. And this validation logic. And it became extremely tedious for us to hard-coded, which is what we've been doing.

[32:00] So I, I just tried more and more to make a more declarative way. Of course, I use jQuery because I was still a genius to specify these in sort like a domain-specific language. And I started researching, like, there's got to be ways to declare them if we represent these, these workflows. And so, the more I search Google. I started learning about how people are using state machines for this.

[33:00] And so I start diving into the topic of state machines. And then eventually statecharts, which are an extension, see machines. And I'm like, this is awesome, why aren't we using this on the web? We really, really should, and so there are actually a few interesting projects with steam machines and statecharts. So, first of all, I'm standing on the shoulder of giants. Nothing that I've made is invented, it's all just based on research in the work of others.

[33:00] Some of my favorite tools are. Jakob Beard is a developer who has created Sion as a project which interprets what's called SC XML, and so XML format for describing steam machines. No one likes writing XML. But that this actually makes it really nice and clear. That, and it is a shared format which, you know, can be interpreted by many different languages. So that's at least something that's nice about XML. But you have so many tools for, you know, working with these SD XML machines.

[34:00] So I encourage you to look at Sion, it's probably right, it s cion, so like, it's the same as Lugar, there's a car called Sion with the Lincoln. Yeah, also, there's statecharts GitHub do, which is just a wonderful resource on statecharts in general, including some references to X, state and Scion, and SC XML, too. So that's why I love about SD XML. It's an interchange format, which means if you write in SC XML, it's compatible with many different interpreters in many different languages.

[34:00] You say SC XML, s, SC XML, which together statechart XML, and it was originally used for interactive voice systems. So you know those annoying things on the phone where it's like, press 1 to press one for English, you know, stuff like that, and it just works. YouTube ad workflow press 2 to hold indefinitely and then will disconnect you. Exactly, that's a broken steam machine. Yeah, but at least they're setting your expectations by announcing it, right?

[35:00] Yeah, and in different languages. There are so many other projects that are based on statecharts as well. There's, I forget, what's called like, I think you SCC or something. It's like a seed based statechart interpreter. For embedded electronics, there's Sis Mech Sism IC for Python, even Java has some cool things the Spring state machine comes to mind. It's not SC XML compatible. But also if you're familiar with QT, which is one of those, you know, we talked about electron a lot for desktop applications, but for people not in the JavaScript world.

[35:00] There is QT, which allows you to make these interactive, highly dynamic desktop applications written in languages such as Python or C++. And those also use SC XML on state machines to control app flow.

[36:00] Yeah, what's the name of the old headless browser tester thing? So there's a selenium. Yeah, the other one night watching Webdriver, webdriver, something like that. There's one of them anyway, one of them's made with QT. Oh okay, yeah, nobody's actually. You've seen a lot of, yeah, I even word like inside, car like car in their faces and stuff like that. Let's go so, David. Also, when I see some of the strong typed languages that are being like used in the front-end.

[36:00] Like Elm and reason, I always see things they like, resemble a little bit. So they have these like different states, different actions, and you have side effects, depending on different actions. Are these like? Is the Elm architecture a statechart? or so? It's not exactly a statechart, it does follow state machine principles, too. Especially the in. Honestly, this is one thing that I feel is sorely missing from Reacts, which makes patterns difficult.

[37:00] But Elm has the concept of when your app is in the current state and you send it a message. It's called, I mean, I, I call it events, but in Elm, I think they call it messages. It returns the next day, the app, plus what he calls commands, yeah, and so these commands are. It's a declarative replic representation of side effects to be executed, and in React, the pattern is simpler its states plus event equals next day, but there's no concept of effects.

[37:00] And, of course, we. Have the use of fact hook, but the use of fact hook is based on which properties are which values changed. Which doesn't really make sense, because the only time in effects can execute is when the states changed, and so that's why, yeah, state transitions. So they use. Effect would be more parallel to the activity concept instead of a side effect, right? Yes, and so, to quickly explain, the activity concept is.

[38:00] It's like a side effects that is only active for the states that you're in. So, for example, if you haven't a in effect. Where you have a loading spinner, like something's manually spinning the loading spinner, then that should only be active when you're in the loading states. That would be an activity. Yeah, so I, I remember this, there was a Twitter try that you were involved, they were talking about that. Like, React is really good at the React code.

[38:00] You write is really good at to find things that happen in particular states, but it's really bad at define things that happen when particular events happen. Right, right, so that's probably like the missing, that's the part that is difficult to write with React without a library like XState, and that's so. Another interesting thing about that is that on reason ML, the first version that they had of the React Risen React before this last version that uses the hooks.

[39:00] They had actually an abstraction they had, like the reducer component, yes, they had a good abstraction of updates, and now that they change to use the useReducer hook. It kind of lost. Also, right? Yeah, so I'm not familiar with the latest version of reason Reacts by know that the previous version had something like reason reducer or something. Dot update with side-effects, which makes complete sense because you're representing here's the next state, and here's the effects to execute, which, you know, useReducer.

[39:00] That hook doesn't let you do it, just sit next state. And that's why in Redux, we have all these all ciliary libraries, like a thunk Sagas, the reduce observables. It's because it's not well baked into the real Redux way of doing things, how side-effects run. And it's interesting, like how the Elm architecture holds really well and how the statecharts way of doing things. Which is like side. Effects should be related to events.

[40:00] Yes, it seems to be more like long-lived, so maybe it's a solved problem. Yeah, this in. But that's because steam machines are based on, you know, having these side effects tied to your states. And it's what's called output in state machine language. And so this inspects, like the 1950s. But there's such things as Mealy and Moore machines which determine when. Do side effects happen when you enter state, when you exit a state, or in between states?

[40:00] That's why it was. I don't know, this is sort of my opinion, but it was a little bit silly for Redux to say, yeah, well, oh man just. But the side effects? We don't want to impose an opinion that's up to whoever you could use, thunk or observable, but there is no opinion. There's a well-defined mathematical way of doing it, and so that's why I actually like Redux Saga. For that reason is because they have the declarative notion of side effects, and so that makes it also a lot easier to tests.

[41:00] Yeah, it's really interesting how, like none of this stuff is really new problems. I think a lot of its kind of relegated to the academic stuff, like we were talking earlier. I think my first exposure to state machines was in college, and I never really touched him after that. Like, I never wrote in a code for them was just drawing circles on paper and being like, you know, when this happens, move to, you know, transition to another state, right?

[41:00] And yeah, the stuff has been around for years and years, but sort of hasn't. I think there's, there's sort of a. There's a barrier to taking that stuff, that abstract, academic type stuff and translating it into. Like, okay, how do I use this to, like, build my to-do app or whatever? All right, well, I mean, that's how a functional programming was for a long time. And other academic concepts, yeah, remember, like, flow-based programming.

[42:00] I got super into that. Yours back. There's a library called no flow. Hi, yes, that's really cool, super miserable. Yeah, super, super visual. And it's based on some work that was done, I think, all the way back in the 70s. And they even, like, brought that guy in and to explain to them, you know, his. Thinking process behind it. And it's kind of instead of thinking about state as a machine, was thinking about the logic of the network as Benefi.

[42:00] Like an item. Yeah, it's kind of hard to summarize it, and it's no related concept. So because, yeah, that flow as state machines, communicating with each other, passing, passing messages. And then you sort into the actor model, which is also very old concepts. But mmm, that's yeah. But in general, it seems like we need more kind of education in the industry.

[43:00] Like, I started just on my own, I was a designer, I was a print designer, and then I just kind of self-taught over the years. Like, Ice, oh, you taught myself the concept of version control. I went out and like, I think of these zips, like, let me see if there's no other concept I taught myself, but all this stuff. But Mike Thomas, I don't think. I don't think it's about education.

[43:00] Because, like a lot of people who learned about state machines, like on university, they were like that. This boring class and everything. I think we need, like that weird healer, killer apps being created with killer libraries, and yeah, and the last UI I created in the last. In my last job, I used a website called Sketch systems. I don't know if you heard about that, David. It's like, it's. It's a very easy way to create and collaborate, creating like simple statecharts.

[43:00] Mm-hm. And when I started, like, creating that, it was interesting. I brought to the designer and to product manager, and they were like, Oh, you know, it's, it's like, it's a revelation. I was like, Oh my god, there is a place where we can actually collaborate. And then I remember, I don't know exactly what was, but like, the product design asked, like, Okay, so I want to add like a confirmation if this things happen.

[44:00] You start typing and you see that there were like three new screens created. Yeah, and then you're like, Okay, so do you see like the effects of this decision you made? Like, this is gonna create like three more screens with like five different messages. So this is gonna make like the this is gonna affect the estimates, like this is gonna we need to be careful with. Those new stuff and this is gonna generate more work for the designer, my work for me.

[44:00] Are you sure you want that? So, like once, but yeah, like, it's, it's about if you bring to the table a good solution to a real problem. I think it's like it just starts getting used. I cannot think about creating you.

[45:00] I stay without, at least it. Well, I guess. That goes into like a count ability and like standards. And what do we tolerate in the industry? Like, if somebody shows us, hey, here's this new project, do we tolerate it? And not having any unit tests? If you look at something that has no unit test, you're like, let's bail. It's just finally we've, we've grown accustomed to, you know, we. We expect a little bit more art, we have higher standards, it feels like we need to kind of up our standards a little bit more of.

[45:00] Like. It's clear that you, you know, you, you built this awesome thing. I love it, it's great. But you know, your state management is very implicit. You need to, you know, extract that out. Just like demanding a little bit more, but in a in a positive way of in encouraging people to grow instead of us. Just be like, seems good ship it. Yeah, why? Because, I mean, that costs money, right? That costs a condor needs money.

[45:00] Developers are not cheap. But if you think about it, we spend a lot of our time, you know, depending on how complex the product is, we spend a lot of our time doing one of two things. Either writing new features, which even if a feature seems simple, like add a button there, you're like, Oh well, I have to so many things in so many different screens or fixing bugs. And so those two things, I would say, take the majority of our time.

[46:00] But those two things, you know, with proper planning, can be drastically reduced in time. Which, you know, means you save the company money, you save yourself some time, and you could do bigger and better things. Yeah, I guess partly it's how do we get good metrics around this stuff? So we don't get fired for not fixing a bunch of bugs because there weren't any bugs to fix in the first place. Like, that guy fixed all these bugs, like, yeah, he caused all those bugs, exactly, and hopefully you don't get paid by the bug.

[46:00] Because, yeah, that'd be terrible. And we're just exterminators, we're not really programmers. At that point, yeah, I'd love to hear more about the visualizing tool itself, like how do you used that professionally? Has it been a useful tool for communicating with people, or is it just like a fun toy? Oh yeah, no. Even at Microsoft, like in. In a couple of the projects that I've been working on, I communicate with people on my team also working on the same project using the visualizer.

[47:00] Right now, it's just a way where you could copy and paste your mission code, the exact same machine code that you have in your app. Like from XE, you copy and paste and you put it there, or you could even a. Speaking of sketch systems, you could copy and paste, as you mean, there's a button for exporting to XState JSON. Funny, nothing sketched up systems. But anyway, I'm actually in the middle of working on an updated version of the visualizer, and some of the big updates are.

[47:00] It's going to be, of course, there's going to be updated visuals, it's gonna be more visually nice and the arrows are gonna be better and stuff like that. But also it's going to give you the ability to save your visualizations, your machines and share them with anyone. And that way, you could just share link. And they'll be able to play around with it, maybe fork it and edit it themselves as well, that'll be awesome.

[48:00] Yeah, yeah, yeah, it very much reminds me of the no flow stuff, yeah, and flow hub, mm-hmm. Except it seems a super focused on just the logic, not on the actual implementation of the logic, right? And so that's what state machines Missy charts do to is they push implementation details to the edge. And I always love how, you know, a lot of developers say, like, visual programming is not the future. You know, I'm just fine with code.

[48:00] And then they spend two or three hours fixing a bug caused by one typo that they made. Yeah, yeah, it seems like it. We're getting more and more kind of diversity, that's, that's. Clustering around our genetics, some people are genetically more visual thinkers, and some people are more genetically like audio kinesthetic thinkers. But we haven't quite gotten physical interact ability with our code yet, so it is more of a struggle for those people.

[49:00] But finally, we're getting better tools for us. Visual people yeah, yeah, and I'm a very visual person myself. So I like to see what everything is doing at either a higher level or a lower level. Without having to digest the code in my head. Because the place where the code is most understood is whoever wrote it, not the rest of your developers. But if you have a visual representation now, everyone has a better understanding and you have less cognitive load on that and how your app actually works.

[49:00] So it's easier to share the knowledge of individual form. Yeah, and it gives you like a prop to talk through things like you can just point and say, Okay.

[50:00] We're talking about this concept now, so it kind of keeps everybody on the same page. I like that. Not only can you point, you could simulate as well, so, you know, just create simulations of how your app is supposed to work. If we run this, these events in series, then this is the resulting state, and you know, your framework is just a view layer on top of that. Yeah, that's exciting. Yeah, I got to play with this thing.

[50:00] Mm-hmm. Yeah, I'll definitely let you know when the new visualize ourselves. Yeah, give me Alpha access. I. Q A for every awesome [Laughter], this episode is brought to you by Triple Bite. Applying to programming jobs sucks. You have to put the right keywords in your resume. You spend hours and hours on the phone screens and take home projects, and that's assuming the company even responds to your application well. If you're a software engineer, Triple Bite can help.

[50:00] They work with over 400 top tech companies, from big names like Dropbox and Adobe to exciting startups. You do one brief online interview with them, and if you do well, you go straight to final interviews with the company on their platform. It's like the common app for software developers. Triple Bite does not look at your resume or where you went to school. All they care about is. If you can code, I've helped dozens of software developers with various credentials get jobs.

[51:00] And this looks like a terrific way for you to get in and get interviewed and get a job. Without a lot of the hassling overhead, you can go check them out at Triple Byte, Comm, Slash, React, that's triple bite, comm, bite, as in eight bits. As a special offer for listeners of this show, if you take a job through Triple Bite, they'll offer you a one thousand dollar signing bonus. But we're coming up on the hour here is when I move to Pics.

[51:00] Sure, I guess I can go first, so I've got. I've mentioned this one on the podcast before, but I'm sort of going through this book again. It's a it's called atomic Habits by James clear, and it's a good book. It's all about lots of different strategies for how to build habits in your life, how to stick with them, and how to get back on track when you, when you inevitably falter. So that's definitely check out at I make Habits.

[52:00] And the other one is Bullet Journal, which been around a while now, and it's pretty much a to-do list. So, if you like to-do lists, but you would prefer like a tangible to-do list in a notebook versus a bunch of apps or something, bullet journalism is a cool way to do that. It's kind of a little more systemic than just a plain old to-do list. THOMAS cool, so, when thing mentioned earlier is the checklist manifesto?

[52:00] I've owned it for months, I'm finally actually reading it and, you know, underlining as I go. And it's been very interesting for kind of a lot of the same topics that we're talking about here. And as far as, like James clear goes, I guess my second pick is my. I just started a YouTube channel all about diving into advanced objective personality, where I'm learning kind of an obscure, kind of bleeding edge psychological research thing.

[52:00] And this week I just typed James clear, he's a kind of an introverted, slash, extroverted INTJ type. Interesting, yeah, and yeah, you can find that somewhere. Yeah, we'll put a link in the show notes. Yeah, David cut. He picks, picks book thanks tools. Well, one book that I mentioned in a lot of. My talks is Ian works constructing the user interface with statecharts. And the interesting about this book is it was written in 1998.

[53:00] And so you can imagine, and this is back in the days of all Windows 98 and stuff. And he even has an example where he sort of rips apart the Windows calculator and says, like, program. There are quite a few bugs in it. And then he reprogrammed it with statecharts. But it is a really interesting book, where it actually has a lot of relevance to this day. All the concepts in it can easily be applied to modern developments, and there's so many use cases and things like that.

[54:00] Now the thing all warned about is try to find it at your local library because it's out of print online. If you look on Amazon, the prices range from like two hundred to six hundred dollars, because now the print so well, okay, your local library firsts. Yeah, yeah, cool, well, that about wraps it up. So thanks David for joining us today. Having me. Yeah, it's been great. So where can people find you online?

[54:00] @DavidKPiano everywhere, GitHub, Twitter, LinkedIn. I guess I never gone there. Ah, awesome. All right. Well, this has been great. Yeah, awesome. Yeah, thank you. Bandwidth for this segment is provided by cache Fly, the world's fastest CDN. Deliver your content fast with cache live. Visit CA, CH e FL y Comm to learn more. You.