# Collaborative App Logic (Real World React) Canonical: https://davidk.dev/talks/collaborative-app-logic-real-world-react/ Video: https://www.youtube.com/watch?v=wyHs9vSxpjQ Speaker: David Khourshid (@DavidKPiano), creator of XState Type: Conference talk · Event: Real World React meetup · Year: 2022 · Duration: 55:41 · Views: 337 (as of 2026-10-19) Topics: Startups & open source, State machines, XState, React, Visual modeling ## Summary Tracy Lee: How to Get Involved in Open Source: A Quickstart Guide How do you get involved in open source? This is a question I get asked a lot, and surprisingly, it's not as difficult as you may think. In this talk we'll discuss the WHY and HOW related to open source contributions, and also touch on the DOs and DONTs so you can be successful today! ## Key takeaways (quoted from the transcript) - [Music] Hello and welcome to the React world tour, the new York JS React Edition. (0:00) - I got excited about open source, and then I was just like, Yolo, I'm gonna start. (17:00) - If we consider, like the different states in this very simple application, we essentially want a mini video player. (27:00) - We also wanted to go back to Mini, so that is our full logic, and again, we could simulate that so we could say, okay, we're in the full state. (40:00) - I mentioned model based testing because you could use state machines to verify the behavior of your app and not use them directly in the application logic. (53:00) ## Chapters - 0:00 Introduction - 3:00 Hasura really redefining GraphQL and hosted GraphQL… - 5:00 I mean, open source is very much about giving back to… - 14:00 I think, Blitz Js as well is another really amazing repo… - 18:00 Your maintainer's biggest priority, you know again, in open source… - 22:00 Pleased to welcome to our virtual stage - 25:00 You know, my apps are simple enough like I could understand… - 28:00 When we're in the full state and a toggle event happens… - 47:00 Where, even if you're not using XState or the Stately tools… - 49:00 With creating models like you could create state machines… - 54:00 The useEffect hook is one of those things… ## Transcript [0:00] So, [Music] Hello and welcome to the React world tour, the new York JS React Edition. My name is Benjamin Dunphy and in addition to organizing the new York JavaScript meetup group, I also organized the two largest meetup groups in the San Francisco Bay area. Additionally, I also produce React-a-Thon, the largest independently organized React conference in the US. And tonight, I'm excited to feature two incredible speakers who will be talking about practical steps to contribute to open source. [1:00] As well as making your application logic, visually collaborative. But first, I'm humbled and privileged to recognize the co-organizer of this event. This dot, this dot is a force in the world of modern technical consulting, agency work and community engagement and events. They partner with enterprises to provide architectural guidance, staff augmentation, on-demand experts, and more. So, if you're interested in learning more about that kind of stuff, head over to this dot Co. [1:00] That's this dot Co. Okay, so before we get to our talks, I do have one quick announcement that I'd like to make, as I mentioned in my intro. In addition to the meetups that I organize, I also organize React-a-Thon, the San Francisco React conference. And while it's been two years since we were forced to take React-a-Thon online, we are returning in-person this may. At a beautiful, gorgeous, incredible outdoor venue, called the Cal Shakes Amphitheater, and this is in San Francisco's East Bay. [2:00] So in addition to the beautiful fully outdoor venue, we have so many amazing speakers that we are featuring. Including Ryan Florence Sweezak, Lee Lydia, the folks from infinite, red, Gant Labord and Jamon Holmgren, and even our own, David Corset, who's speaking today. And we also have a full day of talks dedicated to serverless on may 5th. Called serverless in the Park and serverless in the Park features some of the biggest names in serverless edge computing and infrastructure as code. [3:00] And then, finally, I'd also love to call out our sponsors now this group of sponsors is not your typical sponsor expo. [3:00] These companies are really pushing the boundaries of web development and just engineering in general. Versailles, we all know them, the company behind NexJs and is really making moves, to contribute to the forward progress of other frameworks such as next, as well as Svelte. Hasura really redefining GraphQL and hosted GraphQL, and then so many other incredible sponsors. So these aren't just going to be booth staffed by recruiters, they're staffed by senior engineers. [3:00] And so your conversations that you have with the folks at these sponsor booths are going to be incredibly valuable. Not just for the academic curiosity of the problems that they're solving, but because perhaps they can solve problems for you that you know you're having, but you just don't know the solution to. Or, even better yet, they can solve problems that you didn't even know you were having. So, come and chat with them and hang out with hundreds of some of the top front end and full stack engineers in web development. [4:00] Okay, so that's my little pitch there. Let me stop sharing screen here and let's get into the talks, all right. So our first speaker is the co-founder and CEO of This.Labs, a JavaScript consultancy helping teams build web and mobile applications. She's also a Google developer expert, Microsoft MVP, GitHub star, RxJS core team member, a women tech makers lead, and a frequent keynote speaker at conferences. And given that wealth of knowledge and experience, she's going to tell us how you can get started with open source. [5:00] Discussing both the why and how, in addition to some practical do's and don'ts of contributing to open source. [5:00] So I'm really excited to welcome to our stage. Tracy Lee Hey, thanks for having me. I'm so excited to speak today. Absolutely Tracy. Nice to have you. Thanks for helping to co-organize this. You're co-organizing and speaking. This is just incredible. It's so good to have you. How are you doing today? Good, yeah, very excited to be here. Excited about React-a-thon for sure. Looks like a really good lineup. So I know, yeah, I can't take credit for that. [5:00] Folks are just really excited to come back and I'm just putting it together, that's amazing. Yeah, all right, well, I'm really excited for your talk. I'm gonna hand it over to you. I'll jump off the stage and start your slides. So why don't you take it away? Great, thank you, awesome. Well, everyone, we're gonna have a little chat today. And you know, if you are excited about, you know, open source, or getting involved or building your career, this is. [6:00] Definitely the talk for you. So, I get this question a lot, how do I contribute to open source? Because, you know, it seems like such a nebulous thing, right? But it's actually quite easy, and there's so many different ways to do so. So definitely don't let, don't let you know the idea of doing it intimidate you. I promise you it is very chill and everybody is very chill, people are really nice. [6:00] So, this is a quick start guide on how to get started. As Benjamin said, you can follow me on Twitter. At Ladyleet, I'm the C.E.O of a company called the Salt Labs. I love doing things related to the community, so feel free to hit me up anytime. Find me on Twitter. Love this dot, love the clients we work with, we get to do some really amazing stuff. So we're hiring. And this is also how I make friends. [7:00] So feel free to, like, slide into my emails and have a little chat with me if you're interested in changing jobs. Okay, so let's get started. I'm gonna first talk about, like, you know, other people's journeys into open source. Some of you probably know my story as well. Then we're going to talk about why you might want to contribute to open source. Then you'll learn how based on that, and then just a few, do some don'ts as well to consider. [7:00] So let's go ahead and just start with stories. Sarah Drastner, you all might know, Sarah, she was so funny because she said, you know, when I started, when I first started with open source, I like, made 100 private repos and sucked. They all sucked. I was scared to make them public. I made a lot of code pens and, you know, that was less scary. And then, you know, she asked JQuery to add support. [7:00] And like, they were like, no, and then maybe, and you know, finally, she was just like, look, I'm going to stop, like, asking for my permission, and I'm just going to, like, do my own stuff. To make, developers work faster. And you know, fail, fail, fail, succeed, succeed, succeed again, and then amazing, you have great success, so it's, you know, it's, it's, it's a path that a lot of. People follow, like Kent, for example. [8:00] Ken C. Dodds, he said. I didn't start in the world of open sources and maintain our projects. He had his very first pull request, and it was just fixing a typo. I promise you, maintainers love that type of stuff. And then he just spent countless hours writing JavaScript for companies and working on the weekends, and then he became the Kent Dodds that we all know and love. So again, you know, it starts off with just doing really small things, my journey into open source. [8:00] I mean, I was going to a boot camp, I was meeting people in the JavaScript community because I was like, excited. So, you know, first things first, join the community. You know, this 100 dubs hashtag has been so popular these days. And I've been seeing people go through that. And you know, they formed their own little community, right? Or, Dev.2 has a really amazing like Dev discuss kind of hashtag thing as well. [9:00] So just joining the community, meeting them, you know. And then I think the second thing is just sharing and educating, right? Like you're on a journey, whatever you're doing, it doesn't matter what level you're at. Blog about it, talk about it, talk about it online, you know, laugh at the things that you couldn't figure out. And you know, help people when they're asking for help online, right? The third thing you should do is just meet maintainers. [9:00] So going to something like React-a-thon or even hanging out here, for example. And saying hi in the chat, you know? This is really important, right? Like I met a lot of really amazing open source maintainers and develop relationships online, at meetups, at conferences. And if you're just like nice and friendly and helpful, the rest will come right. I mean, open source is very much about giving back to the community. And then, you know, the fourth thing is contributing, so for me, I always knew I wanted to give back to the community. [10:00] My friends were on the RXGs core team, they were struggling with documentation. This is when, like, there were basically like no docs between, like there was ARCGIS for docs, not RxJS five docs. So I just gathered a team and we all. Got jump started on the docks and, you know, that was awesome. So again, it's it's not as scary as you might potentially think it is. So, hopefully those stories inspired you a little bit. [10:00] But when? Then let's talk about, like, why, right? Like, why do you want to contribute to open source? I think there's two different ways to do that, or two different approaches. You might have a third potentially, but you know, are you most functional? Are they aspirational, right? So when you have more functional goals in open source, it might be means that you are looking to fix something that's not working for you. [11:00] So, you know, maybe it's for work, typically it's for work, right? And then another way you might be thinking about contributing to open source is aspirational. It's a great way to build a career, get new jobs, increase your, increase your knowledge. And both paths are totally awesome, but they're like a little bit nuanced as well, I think. Specifically functionally, right? Like if you're working within a framework or technology and it's open source. [11:00] And you know you're going to need some help in the future, right? Like, maybe your job is like, just to make this thing work at work, right? Number one, give before you ask. Your life is gonna be so much easier. If you're already a contributor to the community or the repo. Or you're, like, you know, helping out in some way or form and you're visible. Do that before you actually have to ask for something. [11:00] You know, the second thing is just, you know, making sure that, you're submitting an issue first and asking for feedback. I think we all have opinions about what we would want changed in different libraries and frameworks out there. But, you know, there's probably a reason why it's not the case. Like, for example, if you, like, went into the RxJS repo and you were like, screw TypeScript. I'm converting this all back to JavaScript because it's a better idea. [12:00] You know, you're probably going to be wasting a lot of time actually trying to do that without, like, maybe like, asking for feedback first, right? So make sure to do that. I think the third thing is just making sure you're like, finding maintainers. On the forums, building relationships, you know, there's this guy. And he like, wanted to make some updates to RxJS documentation. Because, you know, not that recently. But there was a recent release and the docs are a little bit out of date. [12:00] So, you know, he, like, found me on Twitter and he was like, Hey, you know, there's these two PR's open, like you think you could, like, get them merged in or something. And you know, all he needed to do was reach out and say, hi. I mean, I don't listen to my get notifications, I think a lot of us rarely do because they're so noisy. But, you know, because he sent me a quick little Twitter DM, I was like, yeah, sure, totally, you know. [13:00] And then, you know, we were able to merge in those PR's. So finding maintainers on other forms, I think, is really important. I think the fourth thing is like just building genuine relationships. So nobody likes to feel used, right? You don't want. Like, if somebody's like sliding into my DMS, I'm like, EW, you're like trying to use me for some reason. It's gonna feel kind of gross, right? And I'm not gonna like, be interested in talking to that person. [13:00] But you know, if they're like, genuine people and they say, Hey, what's going on? How are you? Oh, I really loved the picture of the pie you posted the other day, you know? Again, it's just building random relationships, you know, I'm much more likely to talk to that person in the future when you talk about things from an aspirational perspective. [14:00] I think this is. This is something I really like because you can be so much more open in terms of, like, who you work with and what you work with, right? It's not, it's very different from functional, because when you're functional, you know, you're probably working on. Like, let's say a React project at work and you have to get something working in React or a React adjacent library, right? But when you are just trying to build a career, you can do whatever you want. [14:00] So the first thing to do is just really look at the different repos and ask yourself, can I be a successful contributor in this? Do I really? Like this team, three of my favorite repos to like look into from a contribution standpoint are definitely Redux. Because I think Mark Erickson is totally amazing and he has things like, really set up for people who potentially want to contribute. I think, Blitz Js as well is another really amazing repo to contribute to, like the way the project's set up, how welcoming it is. [15:00] And then also read with JS. So, all of these things are like, React adjacent. So, yeah. But you can look and you can say like, do I like these people? How's it set up? Is there even anything I can like, contribute to here, right? The second thing again, and just like what I said in functional, like, making sure you're solving problems that maintainers want. Don't like, stick something in there, or like, spend like a day trying to like, do something before. [15:00] Like submitting an issue and saying, like, Hey, what do you think of this? The third thing is definitely helping with the documentation. 99 of maintainers are always going to say, like, Oh my gosh, please just help with the docs, please, please, please. If you're using a technology and you're like opening the documentation all the time, I know you are finding bugs or like things that could be better. Like, hey, maybe I should like submit an example here? [16:00] Or maybe this example is broken, or like, maybe there's a typo. Documentation always needs help. So, you know, you might as well. And then I think the fourth thing is just making sure you're educating and sharing, right? Like, talk about what you're doing, talk about the challenges, talk about the upcoming releases, talk about what you're. You know, what, what you see them doing in different repos. I remember going to this meetup in Australia and it was so funny because the last half hour of the meetup was this. [16:00] The guy, the organizer and he's like, so let's check out this repo. So I saw this comment here. And this probably means that this is going to happen for the next release, or do you think that they're going to be adding this feature? Well, you know, and he's like, kind of trying to be like a detective and like putting together all the. Puzzle pieces. So yeah, but like, educating and sharing that type of information is really important. [16:00] You know, a great example of, like another person who you all might know is Brandon from Blitz Js, right? So, you know, he was, he was funny when he was telling me the story. He just said, you know, I did some trivial fixes, like I made a few contributions. I got excited about open source, and then I was just like, Yolo, I'm gonna start. Blitz Js and Blitz..js has been a really amazing project. [17:00] That's kind of like taken off in the past, year or so. But you know again, like you never know, you never know what'll happen. All you have to do is stick your foot in, quickly before you talk. Yeah, like before you stick your foot in is, let's just talk about some do's and don'ts. Make sure that you remember that, like people are people, right, so have compassion. Treat maintainers like people, be professional, like make your make sure you're like assuming the best of intentions with people. [17:00] Like, you know, we all can look at code and be like, what the heck was this person thinking? Uh? And then, you know, you typically find out that was like you committed that code, right? So just making sure you're assuming the best of intentions. [18:00] Like, a lot of technical decisions are made for different reasons, and you know, you weren't there when those decisions were being made. So, like you, context is really important, um. But nobody likes, you know, being yelled at and being like, why the hell did you do it this way? Like, what is going on? Making sure you're always abiding by code of conduct, too. You know, most projects have code of conducts. But I think like the most important thing is just to treat people nicely. [18:00] And you know, be nice, be nice, don't, I think don't, after be entitled, so basically, make sure to be nice and patient. Somebody's not responding to an issue that you, filed. It's probably because they're sleeping, or they're busy, or like whatever, or maybe they didn't see the notification. You know, there could be so many different reasons why. So yeah, like, be patient and don't act entitled. Also, don't think. Your maintainer's biggest priority, you know again, in open source, like people have, like, literally a full-time job and a full-time job in open source. [19:00] Or if they have a full-time job in open source, they also have a full-time job, like outside of open source for open source. So just imagine having to juggle like a million things like that, and maybe having kids and having a life. And like, dealing with everything, right? Like, nobody's probably ignoring you for like any good reason outside of, like, they just have stuff going on. Don't be annoying, like, follow up, but like, don't follow up 10 times a day. [19:00] Follow up within reason. I highly encourage you to follow up too. I think most people don't follow up and they just give up. When there is an issue, but like, yeah, it's important to reach out, and you know, like, don't give up, talk, also, don't complain. Make sure every you know, make sure you realize that everybody's actually trying their best. And you know, you are getting something for free, so if you don't like it, go use a different library. [20:00] Hopefully again this helped you guys a little bit. I mean, I hope these stories were a little bit, you know, inspiring. Hopefully you have a little better idea as well of like, you know, maybe, like putting words into like, your why? of like, why you want to contribute. Hopefully that helps focus you all a little bit. Hopefully you had some good tips on, like how as well, and some do's and don'ts as well about the community. [20:00] But you know, if you do have any additional questions, or you are looking for, like libraries to contribute to, or anything like that? Well, this thought actually, we just did, a release called Framework..Dev, so check that out. And you know, we always welcome PRs there. We have a few more open source projects we're releasing soon as well. But yeah, you can always feel free to email me because I always have ideas about like, where to contribute and things like that. [21:00] But yeah, we're also a team of about 50 developers and we are hiring so you can come work with us. I would love to again make new friends on the internet. It's like, my favorite thing to do. Hopefully you all enjoyed, and that is all I have. All right, the virtual applause. I know it's still. After all these years, it's still awkward and weird. But I must give you an applause for that because that was such a good talk. [21:00] I love how you structured it, giving, like just very concise, practical feedback on giving. Before you ask, submit an issue. Yeah, ask for feedback, find maintainers in other forms, build genuine relationships. I love how that's. That's seemed like a common theme here is the humanity behind, the open source projects. So often, especially if someone is just coming across this open source project that may solve their problem. And then they're like, Oh, no, but it really doesn't because of this one thing. [21:00] And then they're all frustrated because their project isn't working this, this open source project isn't doing what they wanted. [22:00] And then they kind of take it out on the maintainers, which? But it's like, Hey, hold, you know, pump the brakes there, these, yeah, these are some humans running this. So, be professional, assume the best of intentions and, of course, abide by the code of conduct. So I loved everything you had to say there. Yeah, thank you. I really appreciate that. Yeah, so, thanks again for coming by. Yeah, absolutely. This is. [22:00] The other awkward part is throwing you off the stage. There needs to be more, more graceful way of doing this. But, I guess I'll just I'll press the button softly. Thanks so much Tracy. Thank you. I'll talk to you later. Bye, bye, bye. Okay, wasn't that such an amazing talk? I'm I'm always pleased to feature Tracy at any of our meetups and we welcome her back anytime. But our next speaker is a software engineer turned founder. [22:00] You may have seen him at one of the many conferences he speaks at on Twitter, at David K. Piano. Or in your GitHub feed as the creator and maintainer of XState, his new startup, Stately built on top of the open source library, XState includes a visual editor for building your application logic to make it more accessible for developers and non-developers alike. And today he's going to talk about just that how to build application logic collaboratively. [23:00] I'm. Pleased to welcome to our virtual stage. David Corsid, let me switch to this view. David, how you doing? I think your audio is cut, let's try that. Oh, I did the classic thing where there we go. That doesn't happen in live presentations, but, online, I guess it's still a habit. Yes, how are you doing on this? This lovely evening? I am? I'm doing great. Busier than ever. You know, going from, developer to founder, and we're hiring, so that's been pretty busy as well. [24:00] But of course, I can't think of a better company to join than yours at this moment. Very early stage. You're building an incredible team, so I'm really excited for you and the future of your company. And I just put my foot in my mouth because I think can think of many amazing companies. Let me just revise that, I can't think of a better company. For those who are right fit for you, right, all right, I'm gonna get off here and let you take it away. [24:00] David all right. So, this talk, I'm not actually going to have any slides. We're going to be doing live coding, but not just live coding, we're also going to be doing live diagramming. As Ben mentioned, I'm the founder of Stately AI, the creator of XState. And so a lot of you might have looked at that library or heard about it and thought, like, why would I need this? [25:00] In my apps? You know, my apps are simple enough like I could understand the code that I write. But one of the things that we are all trying to solve here at Stately are like, just this problem of collaboration in application logic. So what do I mean by that? Well, when we write code, we typically write it the way that we, as a developer, right now, would, you know, find the easiest way to write it. [25:00] So I, I have an example app over here where, actually it doesn't really do anything. But imagine that we needed to implement some functionality for making this video go full screen. When we click play, hit play, and then it go back to this collapsed view. So that might be simple enough. You might say, Okay, I'm going to. Just use data over here, like const is open equals, oops, it's open equals use date, etc. [26:00] And, you know, do something like that. But the problem is that over time, you get more requirements, you get more features you have to add, you get more edge cases you have to deal with. And although this is a simple example, this is going to be a good example of how even the simplest of features might not seem as simple. And also, when we write this code as a developer, chances are like, we can't guarantee that the rest of our team is going to understand the logic that we wrote. [26:00] Obviously, they could understand the code and they could follow it and piece it together. But the code that you write does not always match the intents that you have in your head. And so that's the problem that I want to solve. Is this problem of, like, declaratively representing the intent of your application? Logic? With not only the developers in your team, but also with the designers, the product managers, just everyone on your team who is involved in the software development process, in the and especially you. [27:00] A week from now, because I know that I've written code where a week later, I. I have no idea what's going on in the code and I have to sort of scratch my head. And hopefully I left myself comments or some documentation to understand what the code is doing. But, you know, more often than not, that doesn't happen, all right? So how can we describe the logic that we want to do in a way that the rest of the team can understand? [27:00] Well? If you've known me for long enough or seen any of my videos, you know that this is where I start talking about state machines. And so that's exactly what we're going to do. So let's, let's describe the logic of this in a steam machine. I'm using TL drop, which is like Excalidra, I really like it, so, it does arrows pretty well, so that's why I'm using it. But if we consider, like the different states in this very simple application, we essentially want a mini video player. [28:00] Where when you click it, it goes to full and then when you click it again, it. [28:00] Goes to Mini. And so we modeled this as a state machine, and now a state machine consists of. Technically, like the mathematical definition is, it consists of five parts. It consists of an initial state, a finite set of states, a finite set of events, a finite set of transitions. Which tell which state do we go to? Based on an event, and also a set of final states. Now apps aren't, they don't fit the like 100 the mathematical definition of a state machine, in that apps typically don't have a final state. [28:00] Like, there isn't a point where the user says, Okay, I'm done with this app, it doesn't need to run anymore. Typically, we want our apps to be continuous and users to keep using our apps. So, but final states are still useful in some contexts. All right, so let's say that, you know, we have a mini state and that is very small, let me try to bump this size up. Okay, here we go, so our first date is going to be mini. [29:00] And this is the initial state. It is denoted by an arrow, typically with a little circle over here. That shows this is the first state that we enter, you know, when we start our state machine. And so we have another state here called full, and we have transitions that go between these states. So I'm going to call this one toggle, and we're going to add another transition that goes back from full to mini, that says toggle. [29:00] And so just like that, we've created our first state machine. Well, at least in the diagram, and so you could sort of envision how the state machine is supposed to work. We start in the mini state, and when we toggle now, we're in the full state, and so when we toggle again, we're in the mini state. Now. The cool thing about state machines is that, even though this might seem a little bit, you know, a little bit extra, because you could really express this with just a boolean. [30:00] State machines are useful for more than just states and transitions. State machines can also express actions or effects, as you might know them. So I'm going to add some text here and we're actually going to make this small. So when we. Enter this full states. What do we want to do? We want to actually, play the video? And so that means like once the video goes to full screen, we want to trigger some sort of action that actually starts the video. [30:00] Similarly, when we leave the states and it's not in full screen mode, we want to pause the video and we want to pause the video because we don't want it to keep playing. When the user indicates they no longer want this full video on the screen, so, that should be exit. So these are two kinds of actions that you could have an entry action in an exit action, and so just like that. [31:00] I hope you see that there's a lot of value in declaring your effects, or like stating your facts declaratively in your state machine. You could also have effects, directly on your transitions. So you could say, you know you, for instance, you could say, play the video over here, like when you toggle, um. And in fact, that might be a different way to model it, so we might do this instead. Where? So now you're saying, when you're in the mini state and someone toggles the video player, we're in the full states and we're also going to play the video, and then when we exit the full state. [31:00] You know, this could even be on this transition too. We'll pause the video. So, yeah. Those are just examples of, like, the main parts of the state machine, we have our states, our transitions and our actions. In fact, I'm going to move these back over here. And also it goes to show you that there's many different ways, or multiple different ways to, you know, to model these state machines. So how do we represent these state machines in code? [32:00] Well, that's where the, the library XState comes in handy, and honestly, XState is not as big a learning curve as many people might think, especially in React. Because we provide a handy hook called useMachine, which feels very much like useReducer, and in fact, writing machines is a lot less verbose than writing these reducers. So I'm going to say, import create machine from XState, and also we're going to import useMachine from. XState React. [33:00] So a machine is created by create machine, of course. And you specify a few things, you specify the initial state, which is mini, and then you specify how those states transition between each other. So we might have two states, many and full, and so we could say on toggle. By the way, it doesn't have to be capitalized. That's just a habit from when I used to do Redux, and in fact, I don't think the Relux documentation does that or shows that anymore. [33:00] I think it's all lowercase, no more screaming, but yeah, it's just habit anyway. When we go from our. When we're in the mini state and the toggle event happens now, we're in the full state. Same thing over here. When we're in the full state and a toggle event happens, we go back to mini. Now, of course, you might be saying, why would I be doing this instead of writing a reducer or even using a boolean variable? [34:00] And again, you have the option to specify effects directly in your state machine. So we could say entry. In fact, I'm just going to console..log to show you what happens over here. Entered the full states. Okay, so how do we consume this machine now? We, we use the useMachine hook, so we are to say that, use the useMachine hook. So you pass the machine in there and you're going to get two things, just like you could, you know, probably predict. [34:00] We're going to get state and send. So basically the same things that you would get from a useReducer, where in useReducer, you get state and dispatch, except in X.C. We call that send. So when I click the player instead, I'm going to send that toggle event and notice. I'm not doing any logic in here other than dispatching or sending an event over to the state machine. And we're going to console.log the state.value over here just so you could see what's going on. [35:00] Okay, so right now we're in the many states, as you could see over here. Now when we play, two things happen, we go to the full states. But we also execute this side effect. So now you can see it's it's pretty handy to have that just in there instead of. Having to have a useEffect and figure out, okay, when is this effect supposed to execute? Which, by the way, at React-a-Thon I am giving a talk on useEffect, so, please register for React-a-Thon and don't miss my talk. [35:00] It's gonna be a fun one, I promise you. So, anyway, yeah, that is, you know, how you interact with the state machine. You know, we have toggle, so, I mean, nothing much is happening here just yet. But, we actually wants to, you know, show something in the UI that shows like, all right, you know that this video is actually toggling between full and mini. Before this presentation, I set up some styles, so that the data state attribute when it changes to full, it's just going to go full screen. [36:00] So, I mean, there's many different ways that you could render these states, I'm just going to use data attributes just because I really enjoy doing that. So I'm going to get the state dot value, which right now it's a string you could have nested in parallel states and then it becomes an object. But right now it's a string. So we're just going to have it as state.value. And so now you can see, when we click here, it goes to full screen and then when we click outside, it sort of shrinks back. [37:00] Now, getting back to the original point of my talk. We have a state machine here, and this might be marginally better than just code, you know, at least if your entire team understands state machines to some level. But it's still not fully there in terms of collaborative. Like, how can we actually take this and show a designer, or show a project manager, what the logic is supposed to be? And so that's why we have, a visual editor that sort of lets you have that. [37:00] By the way, our own Madpoc just became a developer advocate, so that's why that's there. But now we are going to make our own state machine, and we're going to do it a little bit faster than coding, too. So I'm going to call this a player state machine, and we're going to add a couple states. The first state is going to be mini and. I could click here, make a full state and then we're going to connect the two. [37:00] So we're going to say we go from mini to full on toggle, and same thing over here and toggle, we go from mini to full. So just to test the logic of this, I mean, this is obviously pretty simple. But we could see that we're going to go from mini. And when we toggle, we go to full and then we toggle, we go back to the mini state. And so you could think of this as a diagram editor, because we are creating a diagram. [38:00] And this is something that you could show, you know, project managers or designers and say, here's, here's how the logic is supposed to work. And you could even add descriptions saying like, the video is a small image, not playing. I have to fix that a little bit like there. But yeah, you see the description right over there, and yeah, so, you know, you could describe, you know, just different, you know, different things. [38:00] You could have an action like that. So let me refresh this real quick. There we go. Yeah, so here, let me just delete this and then you could also add a description over here. So now I actually also want to add these actions because we do need to say that when we enter the state. We want to play the video, so I'm going to add it here, and when we exit, we're going to pause the video. [39:00] And so now this describes all of our app logic, or at least most of it. So, you know, we toggle between mini and full, but now we have some additional requirements that we have to do. Not only do we want this to go back to the many states when we toggle it, which means when we click the player, but we also want to, maybe when the video ends. So if I have a video dot ended event, we want to go back to the many states. [39:00] And this, you know, might also be confusing, because it's like, okay, how is this possible? So we could add a description and say, when the video API sends an ended event and just have it directly on that. Event over there. And we could also, you know, create another transition here. That says when we press the escape key. We also wanted to go back to Mini, so that is our full logic, and again, we could simulate that so we could say, okay, we're in the full state. [40:00] And now many different things can happen. We could toggle and go back to Mini, or the video can end, and we could go back to Mini as well. So the cool thing about this is that, this isn't just a diagram, it's actual code, at least JSON code that you could use directly in your state machine. So we go to Stately AI, our visualizer, and we copy and paste that in here, then you can see that this is actually working code that you could use. [41:00] And so everything you know from our editor is here. And so this is just a nice little play playground for, just testing that everything is working. So I'm going to go ahead and copy that code and we're actually going to use that for our application. So, you see, we have the description in here, still a little new line over there, and it's still going to work where we go from full to mini to full. [41:00] And you might notice some warnings over here that say that we don't have implementations for play video, pause video, play video. So let's go ahead and add those real quick, in XState again, it's not just for managing states, and not even just for visualizing states, but also for declaratively expressing effects. So we could say actions, play video, and we have a video ref set up so we could just say videowrap.current.play. And so let's test that out and make sure that works. [42:00] So right now it's in Mini. When we click, it's going to go to full screen. But you can see once the flower is done blooming. After five seconds, it sort of just stays there. So we do want to implement that other event, which is, or we actually, we want to transition, back to, um. You know, when it's closed, when the video ends. So let's do that real quick. And, you know, for now, we're going to use a use, an effect. [42:00] So I'm just going to say, useEffect and that's video ref dot, current, dot, add event. Listener ended. And we're just going to send video.ended to the service or to, you know, to this. And so now we're listening for that ended event and we're translating that to a video.ended event. So now you could see that when we play and the video ends, it's going to go right back to the many states now we, you know. [43:00] One of the best parts about, I guess, thinking this way, and thinking in terms of state machines and statecharts, is that everything is an event. Like everything that you could do all the signals that happen in your app, those are all events, and the representation, or, sorry, the manifestation of those events, is that they're all states. So, of course, we have mini state, we have the full state you could also have, like infinite state. [43:00] That doesn't fit this by adding context if you wanted to. But yeah, so, let me just add I'm just copy pasting here for time. But we're also adding an event handler for the escape key, so we could see that when we're playing a video and we press the escape key, it's, it's going to go back to mini mode. But we actually didn't implement anything to pause the video, so let's do that pause video that is going to be the ref.currents.pause. [44:00] And so now you can see, when we press escape, the video is paused, which is exactly what we want. So we could click here again. And then when the video ends, you know, now, now we're there. So, yeah, that's just a quick overview. Oh, yeah. So there's one more thing I want to show. And we, we've shown, like, going from basically this executable diagram and creating it visually to code. But what if you could go the other way around? [45:00] So let's import inspect from X8 inspect, and we're going to inspect, I'm going to the URL of Elite..ai, fizz inspect, and we're going to use our inspector. So now, if you add DevTools true to this machine, what this is going to do? And actually, let me just make sure it does. You don't want this in an eye frame you could put. It in an iframe, if you want, but it's going to open in the iframe and it's going to show. [45:00] This is the exact same, machine that we had before. So now, if we play the video and go back here, you could see it's in the full states. So now, you know, you saw, I went back and we're in the mini states. But check this out, we could actually go both ways. So if I click toggle, it shows full here and it shows full here. Let me play this again, and oh well, it ended. [46:00] So if I play it again and I toggle, it should go back to the mini states. So if you had these side by side, you could see the states transition in real time as your app is running. And of course, you only want to do this, when you're in production, or, sorry, no, only when you're in development. Bespoke there. So yeah, this is like, just using all of these tools really helps you express your application logic in a collaborative way. [46:00] Because now you could add descriptions in the future, you could add, you know, pictures and things like that. And you could also simulate it so that you could describe all the different use cases of your app logic before you even put it into your app. And so with the inspector, you could actually show here's how the app is supposed to work. [47:00] Here's all the possible states that could happen and all the possible events that can be taken in each of those states. And so the exact same code that you write, it. It becomes something that could be visualized and inspected and analyzed. And, yeah, that's why I'm so passionate about using state machines and statecharts. Where, even if you're not using XState or the Stately tools, just being able to describe your application in boxes and arrows can do so much. [47:00] In terms of collaboration, you know, with your entire team, so it's something that I encourage everyone to do, and with that, I'm pretty much done. So I'll take some questions. Or David? Excellent work, thank you. Virtual round of applause for me. And I assume thousands that are watching the live stream right now and millions to come. [Laughter] no, really. Oops. I think I killed you there, there we go. Really interesting talk, I always love hearing. [48:00] Your presentations always very innovative. This is just incredible. How long have you been working on this? Because, I mean, number one, let's go back to you as the creator and maintainer of Stately or Stately, XState. How long? First, let's talk about that, how long have you been working on XState? So I've been working on the X8 for a little over six years now. I first talked about it at a Reacts rally, I think 2017 or something like that. [48:00] And back then it was just a very basic state machine. Library got it, so then you work on that, you realize the benefits of this. This is blowing your mind, or you already knew it was blowing your mind and you were just implementing it. I mean, honestly, just the idea of an executable diagram. [49:00] That was pretty mind-blowing to me, especially as a somewhat junior developer at the time. Just because I thought that there was like, inherently a disconnect between the architecture diagrams or the, you know, flow charts that we drew in the actual code that we implemented. And as a developer, I've experienced a lot of like, here's a user story. You have to somehow translate that into code, and the user story might change. Or the code might change so, or the diagrams may change. [49:00] And there's never like this synchronization between all of them. So when I discovered state machines and statecharts, and how they were basically created for the purpose of. Like, having this, you know, this shared communication with everyone and having these diagrams that stay up to date. I, I became hooked because I'm a very visual learner, so I just like seeing things visually happen when I do things in my app. So it was pretty mind-blowing to me. [49:00] Yeah, and I like your reasons for it. Not only sharing with people who are other engineers to understand your code, but also for yourself. Months down the road, or even, well, a few weeks, absolutely coming back to that code. What was I doing here? Visualizing that is very incredible. I'm curious, you know, you showed some new code here we talked about writing user stories for. New features, that's all Greenfield stuff, which is amazing. [50:00] What about Brownfield? How can XState and Stately help you there? Oh so, yeah, there's actually a huge opportunity there, and one of the best opportunities comes in the form of model based testing. Which sounds a lot scarier, like state machine, sounds scarier than it actually is. But it's a way of. You could take any legacy app and if you want to do any sort of refactoring or adding features. Like, there is that requirements that you really have to understand, at least at some level, what's going on in the code. [50:00] And so, typically, what developers do is they create a mental model and so you know how it goes. You go to a new company, you have to have one senior developer or a couple. Tell you like, Hey, here's how our code is. Don't worry about that parts, this code, we don't know why that works, but don't remove it because otherwise things won't work. Like just all of this, like inherent knowledge that, you know, you just have to pass down from generation to generation of developers at the company. [51:00] But with creating models like you could create state machines, that sort of, they're not part of the app logic, they just describe the behavior of your application and you could use those for testing. And so once you do that, and you, you use these models to automatically generate like tons of tests. Then you could basically take those models and start re-implementing logic, because you can be sure that those models actually do represent your application logic faithfully. [51:00] So that's an opportunity, and another opportunity is, can I just ask a follow-up question on that? So that's basically rewriting the code by following the application logic from the from the state machines. Is that correct? So it's like it's basically a rewrite, sort of in a way. So I, I was actually just about to mention that, you could use state machines at any level of the application. So, typically, what I see teams doing is they say, like, all right, our app is like legacy, Redox or JQuery or whatever. [52:00] You know, maybe it's just use producer, or maybe it's using just very old React stuff, class components and such and so. They would say, Okay, we have a component here. We could either refactor this small part of the site using state machines, or we could maybe create something new using state machines. And since it's not like a state management library where it has to be all or nothing. You could use it for specific parts. [52:00] And then, once the team gets more comfortable with it, you could start refactoring these, these things. So at the end of the day, a state machine is really a fancy reducer, so anywhere that you would use a reducer, you could use a state machine. So I mentioned model based testing because you could use state machines to verify the behavior of your app and not use them directly in the application logic. But just mentioning that as another way of, I guess, introducing the idea of state machines into Brownfield apps, that's incredible. [53:00] Really excited for you, really excited for the future of Stately and XState and just state machines in general. It's it's really interesting. Thank you. Yeah, so I wish you the best of luck with that company. I really look forward to seeing you at React-a-Thon in your and your talk there. Do you wanna do you wanna give a little preview about what you're gonna talk about at React-a-Thon on may 4th? Sure, yeah. [53:00] So, unlike my previous talks, this one is actually going to be. I am going to mention state machines. But just in the theoretical way, it's more going to be about useEffect, and so, in working with React applications. [54:00] For so long, you start to realize that like that, there are some things that don't 100 percent make sense and you can't really figure out why. And so the useEffect hook is one of those things, and so I'm going to talk about like, some new information, especially with React 18 coming up on just how you should really be managing your effects. And so, you know, some things might surprise some of the audience members. [54:00] Like, there's lots of things that you're doing in useEffect that you actually should not be doing in useEffect, and React 18 also introduces some new behavior with useEffect. So, we're going to be talking about different ways, better ways to think. About just effects in your application in general, and how to really navigate the weird world of the useEffect. Hook. With regards to that, very interesting, all right. So I'm sure people can catch you there. [54:00] Both around the conference and also at your sponsor booth, because staying here will be sponsoring, so we do appreciate that. David, thank you so much for your time today. It's been really interesting. Look forward to seeing you next month. All right, thank you Ben. See you guys, bye-bye, all right, and that's all we have for this meetup. Thanks to everyone for coming out, thank you for watching if you're watching after the fact. [55:00] And thanks to both of our speakers, Tracy Lee and David Korshad. And to this dot who really helped to put this together and wrangle everyone together. That's all. For now, I'll be signing off for today. Hope to see you at React-a-Thon in may. Oh, that rhymed, all right. Take care bye.