Transcript from the "Wrapping Up" Lesson
[00:00:01]
>> All right, well, i'Il open it up to questions. Now if you have any questions about just anything that we talked about in the workshop. I do wanna show you one thing though, if we go to code sandbox.io. And I'm gonna let's explore search sandboxes and the type x state view even though this is a a reacts workshop i wanna show you that the reason that we centralize and we put all of our machine logic and application logic within one machine.
[00:00:48] The reason that we do that in next state is cuz our logic becomes something that is completely agnostic to basically any framework. So we could essentially copy and paste that exact same timer machine, put it in a view app and have the timer work the exact same way.
[00:01:10] So this is something that's really useful, especially if you're not committed to a framework or you wanna share this between frameworks. Or maybe you wanna share the exact same logic between react and react native. Or in the future if you want that same logic to be on the both the front end and back end or in a different language altogether, like there's a lot of possibilities here.
[00:01:34] And so that's why i really enjoy working with state machines and state charts as a declarative way of specifying your logic. Cuz, you could create the exact same logic in a view app. So yeah. All right. So, i guess i'll open it up to any questions about basically anything that we talked about in this workshop.
[00:02:05] You were saying how, the machine is language agnostic, even application agnostic it. So it's just super portable lwe're Robson loading is a j s object here. But someone was mentioning before about serializing it potentially or code gen tools to, as part of a build step have it included in the back end to or wherever you need it.
[00:02:34] Yeah so the question was about just the usefulness and basically the possibilities of having this declarative format for a machine and using it pretty much anywhere and i actually really wanna show you this thing that has absolutely nothing to do with react, or even JavaScript at all, but is really cool.
[00:03:03] So someone shrivel up. He made a code generator that generates c++ code. From an X state machine. So basically you can take these X state machines and run them within a C++ application, which is something that i haven't even dreamed of doing. And yeah, so that's definitely a possibility right there.
[00:03:30] Just to show you how far you can really go with this. I had a question actually about the clock, the foreign clock. And so, yeah, so you are fetching some data, from this world time API. And you chose to use the react query library for that, but. Would you in general or why wouldn't you why wouldn't you do that query as part of the machine so, lwhat you're doing is getting it and then you having to do an effect and inject it and all this kinda stuff, right?
[00:04:05] But wouldn't you in general maybe prefer to add that as an invoked step within your machine.
>> So, yeah, that's a great question. The question was about the use of reacts query over here to fetch data and to do that separately from the actual machine. And so the answer to that is sorta two fold.
[00:04:32] First of all, i did it to demonstrate how you would use a third party library. A third party reacts library with that. But also reacts query currently doesn't expose a way to do all of the caching magic that it does. So reacts query is a really great library for actually managing the caching of your resources so you don't over fetch.
[00:04:57] So if i'm doing something, i go to another component or components unmounted, and i remounted it's gonna call that query again. But the query is gonna say, i already cached this exact same thing that you want. So here you go. And obviously, xe doesn't have that caching magic.
[00:05:18] But reacts query internally has this cache that's really smart about, when to evict things from the cache or when to hold things. And because it doesn't expose it as a, as a framework agnostic, tool or API, we're sort of stuck with using the hooks for that. And Apollo clients sorta has the same problem except that with Apollo clients, i really actually like that.
[00:05:49] It does expose the actual clients for you. So if you don't wanna usethe hooks, you could use that clients object itself and be able to. Put that in an invocation or even as a side effects like you using actions the next day.
>> Right?. Yeah, so okay, so i understand that in fact we use react query a little bit, as well for those same caching reasons.
[00:06:15] More what i was getting at was just there's no real reason other than maybe i want that extra caching function or whatever, to just put my fetches and stuff as as invoked. Effects within the machine that's fine, right there's. People do that that's a cool thing to do that there's no real reason other than, i'm getting this extra function out of some other library.
[00:06:39]
>> Right. Yeah. So again, the question was about using, react query versus doing everything in the machine if you wanna do everything within the machine.
>> That's definitely allowed and once reacts query hopefully in the future once they have that, their caching technology able to be just imported without needing to go through a react hook.
[00:07:04] Then i will definitely. Or someone can definitely make a library or you don't even really need a library for that. You could invoke that yourself and use the cast directly through either actions or, invocations.
>> Yeah, i was gonna say somebody needs to make basically an xstate backed version of react query and react router.
[00:07:28]
>> I wanna i definitely want to.
>> [LAUGH]
>> Every time i think about exit i'm man, somebody needs to make a rap router available.
>> [LAUGH] Yeah, well what's funny is, Amber a long time ago, someone actually made a, Ember router using state charts. Look at the year 2012 in 2012.
[00:07:52] I was struggling with j query. I wasn't doing anything related to state charts or state machines, but Ember very, early on. They were actually using statecharts all over the place. So again, this is not new technology. And funny enough, Ember was the first one to do it or at least in the front end.
[00:08:14] My last question, so one of the biggiest difficulties I've had is dealing with the types with this. Going through GitHub issues and stuff on XState, I know that you're aware of some of the pain points with pipes and some of the problems that are there. In fact, I ran into most of those problems trying to create a react query lite basically that was XState back [LAUGH] because I wanted it but I didn't wanted to use XState.
[00:08:47] Anyway, the types ended up just being an absolute nightmare. I literally just dropped it because of that. But I'm just wondering what are your plans to improve the TypeScript experience for XState? Cuz I see that as being the biggest blocker in terms of adoption at my company for XState.
[00:09:08]
>> Right, so the question was basically the future of XState and typing with TypeScript, which you know definitely is a common pain points and that's for a few reasons. That's mainly because the things that XState is trying to do is sort of outside the realm of what TypeScript can do.
[00:09:29] But basically in version 5 we are going to be improving the typing a lot, and we are gonna be doing it by basically simplifying parts of the API. And also just trying to infer a lot more. In fact, every single time that there's a minor release or a major release of TypeScript, we immediately say, that solves a good chunk of our problems.
[00:09:55] And so we're gonna see more and more of that, especially with TypeScript, you could now type template literals. And so that's going to be very helpful just for being able to autocomplete different states and just targeting states, especially the dot separated states. Now it's very possible to strongly type that.
[00:10:18] Additionally, as was mentioned earlier, there is a project called XState codegen, which is really, really useful. It basically generates the types for you the same way that Prisma, if you're familiar with Prisma, would generate those types, too. And so it advertises that it gives you 100% TypeScript coverage of XState in TypeScript.
[00:10:43] So definitely recommend taking a look at that, because it's going to generate a lot of the types that you would either have to manually type or that you would have a struggle, and maybe look at the source code of XState to figure out how those should be typed.
[00:10:59] So again, version five, there is gonna be a lot of simplification and a lot of clean up of types, as well as using a lot of new TypeScript features in order to get those typings in. And we're also experimenting a lot with inference. So basically making it so that you don't have to pass context and events inside the type arguments or the generic parameters.
[00:11:24] Instead, those are inferred from what you put inside the object. And so yeah, we definitely have a lot of plans there. So yeah, definitely check out XState codegen. I think, for current XState projects, this is probably the most helpful thing. And in version five, I'm also gonna be adding a lot more documentation on TypeScript usage as well.
[00:11:51]
>> There's a couple of questions in chat. Is there a way to generate code from a GUI when you're creating the charts? Okay, so the question was, is there a way to generate code from some sort of program user interface? There will be, there definitely will be. It's something that I'm working on right now, which is basically a drag and drop editor where you could create states and transitions.
[00:12:18] And basically create the entire state chart, export that as JSON, and yeah, just have that auto generated for you.
>> Is there any way we get a preview?
>> There is not [LAUGH]. But I will say that the project updates are going to be on statecharts.io, and so it's basically going to be what you see with the inspector.
[00:12:49] And so this inspector, it already works with many things if you allow pop ups over here. Inspector is pretty much one way. So it takes your machines defined here, and it generates it visually for you over here. So just imagine in the future that this will be something where you could add states, you could change transitions.
[00:13:17] You could modify properties on the right hand side, and those are going to be reflected back in here via a JSON file. And you could pass that JSON file into your machine. And then you could, of course, add the implementation details such as actions, guards, services and all of that.
[00:13:40] So, hopefully I will have a preview by the end of the year. No promises though [LAUGH], but yeah.
>> What are some types of things that you shouldn't do inside state machines?
>> Okay, so the question was, what types of things should you not do inside of a state machine?
[00:14:03] And the simple mathematical answer to that is be non-deterministic. Which sounds like a mouthful, but what that basically means is that in a state machine, every single transition should predictably go somewhere. So there's no such thing as saying on Toggle, and doing Math.random is less than 0.5, go to active.
[00:14:34] Otherwise go to inactive, something like that. That's just not a thing and it's not something that you should do. Obviously that's a really silly example, but there is a reason why this machine is created in such a declarative way. And it's because when you have functions, functions are really versatile, you could do anything in a function.
[00:15:00] However, that's also a problem, too, because one of the best parts about not only XState but state machines and state charts is that everything is predictable. You could predict the future, not even just what happened in the past, but what can happen. And that's just not cool from a, I could time travel in the future type of thing.
[00:15:22] But also when you're explaining the logic of your application, you want to be able to tell people, whether they're technical or not in this screen, here's all of the things that can happen. And here are the things that can't happen. And when this thing happens, this is what the next state is going to be.
[00:15:41] So if you're working on either a plain react application with Redux or use Reducer, just something like that, there's really no way to predict what can happen next without having to, I say there's almost no way. I mean, obviously, you could Take the function as a string and break down the AST and do some static analysis or whatever on that.
[00:16:05] Or you could just use a JSON object and be able to walk through the object and be able to predict, what can happen at any given time, what are all the possible states in my application? Yeah, just making that predictable is the number one rule in using state machines and state charts in general.
[00:16:26] So, in that state specifically, it follows that rule. Don't mutate anything outside of an action or yeah, basically don't do any side effects outside of actions, assign should be pure. I mean, it will work, like we previously talked about, it will work if you mutate it, but again, try to avoid that if you can.
[00:16:52] And yeah, so basically the structure provides that pit of success for you.
>> Had a question about bundle size, I was checking out bundle phobia. I know, x state for react is pretty tiny. It's like 1.4 kilobytes and the XState. I mean, it's not massive, but it's like 16.4 and I know where I work they're like we don't have a lot of dependent third-party stuff.
[00:17:23] But this really interests me and just wondering if there is any work on bundle size or it's not really on the radar right now, or is it really not a big deal?
>> I wanna show you a tweet about that, I guess I can't find it. But [COUGH] anyway there was there was someone who actually used XState in a major project and was able to delete like, I think around 8,000 lines of code, just by using XState to replace a lot of the logic.
[00:17:59] So it's important to note that XState is not just a state management library, it's more of a state orchestration library that has a lot of things built in, which is what does contribute to its bundle size. And XState version five we are working on ways to make it a lot smaller, especially by making it more modular and making it so that you only need to pick and choose what you need and not everything is exported in one giant spindle.
[00:18:28] And in fact, you could use XState that way as well even today. You do have to go through the awkward import for example, create machine from xstate slash lib slash machine or something like that. But yeah, what I believe that the the amounts that XState gives to you in terms of features and what you're able to do with the logic, it eliminates a lot of code, especially in my anecdotal experience.
[00:18:58] But yeah, we are working on shrinking the bundle size. And if you only need state machines and you don't need the nesting or the history or parallel states or things like that, then XState FSM is what you want. It's only around one kilobyte, so it's extremely minimal, but it has the same structure as XState itself.
[00:19:21]
>> Okay cool, cool, that's very helpful. Thank you.
>> Yeah, all right, well, if there are no other questions, then I want to thank you all so much for spending an entire day with me working on XState and react. And just, exploring from the very basics to just some advanced techniques like invoking and spawning actors, what you could do with XState in react applications.
[00:19:51] So I really hope you enjoyed this workshop. Thank you.
>> Thanks so much, David, it was awesome.
>> Thank you.