Transcript from the "Wrapping Up" Lesson
>> All right, Cory asks a really good question, it's a philosophical question. Why do you think that statecharts and state machines are not more commonly used? So what weaknesses might a statechart have related to modeling complexity? In fact, I have a slide for this, and it's the complexity trade-offs between state machines and statecharts.
[00:00:23] So with the state machine, which by definition is simpler than the statechart, the complexity of state machines is really small because you're only dealing with a finite set of states. But as soon as you have multiple states, you have exponentially more transitions. And it becomes a lot more complex than statecharts, or even your normal bottom-up programming.
[00:00:46] With statecharts, the learning curve is a lot steeper at first, and it might seem like overkill. But once your app gets to a level of complexity, you're going to see that statecharts compose really well in order to mitigate the effects of combinatorial explosion of states or added complexity.
[00:01:06] And with bottom-up, since every single place you write a feature or you write something in an event handler, you have to check everywhere else in the code that might touch that. It's just a linear growing complexity because the more you add, the more edge cases you have to deal with, and the more defensive programming you have to do.
[00:01:25] So statecharts are not more commonly used, I'm really hoping that they will be. And that's one of the goals of this workshop, is to educate you about statecharts and how you could use them to your benefit. But statecharts are not commonly used right now because it is a big learning curve.
[00:01:46] I like to say that there's two types of state management libraries, especially in the front end. There's the change state whenever you want driven libraries. And there's the event-driven libraries. So the frustration with event-driven libraries, such as Redux and xstate and MobX-state-tree and other libraries like that, is that event-driven libraries don't allow you to mutate the state directly.
[00:02:10] So it's not as easy, there's a level of indirection there. And you could consider xstate to be Redux but more rigid, because now you have these rules of what you could do in certain states. And so because of that, a lot of frontend engineers feel like it's easier to just mutate state and to put logic in event handlers, and at start, this works.
[00:02:30] But if you've ever inherited an app where you do have logic which is spread out in all these event handlers, it becomes really, really hard for any other engineer on your team to really understand all the logic that's going on. Because there's no central place where that logic lives.
[00:02:49] There's no convenient reducer like Redux has. You have to just piece it all together and form a mental map of it. It's not really the the ideal scenario. Also, statecharts have always been an uphill battle even with David Herro. He wrote something in a newspaper about 25 or 20 years ago, talking about how selling statecharts is still a pretty hard sell because it is a different way of thinking.
[00:03:20] We're no longer thinking in, okay, let's update the state, let's just mutate it directly. Now we're thinking in terms of events, and in terms of how different states can react differently to events. But we see that there's so many benefits to using statecharts. And a lot of those benefits are based around the fact that, like we talked about in the beginning, these statecharts are essentially directed graphs.
[00:03:45] So you could traverse those directed graphs. You could do things such as model-based testing. You could have analytics where you could predict and track just all the different ways your users could use your application. You could transport statecharts between languages. In fact, statecharts are so useful that they are part of UML, like we talked about earlier.
[00:04:08] And so having that adopted by UML means they're used in many different things, such as embedded electronics, automotive engineering, aeronautics, and in fact, many, many other things. And so the concepts that you learn in this workshop are going to be applicable to pretty much anything related to statecharts at all.
[00:04:28] If you search statecharts with any other language, such as C++ or Java or Python, you're going to see that there are a lot of related state machine and statechart libraries out there. All the concepts that you've learned here are directly applicable to pretty much anything that has to do with statecharts and state machines.
[00:04:48] Additionally, there's a spec called SCXML, it was finalized in 2015, it's a W3C recommendation. And If you have the time to look through this ginormous spec, it is a spec for statechart, state machine notation for control abstraction. And essentially, just like it says, it's a way of abstracting state machines and statecharts in, well, XML, which I was gonna say is not really favorable anymore.
[00:05:21] But with JSX, it is pretty favorable now, I guess. And this is a way of defining your machines in an abstract way that could be transported between languages. And so that's one of my goals with xstate, is to enable you to define these machines and statecharts in a way that could be used in any framework or no framework at all.
[00:05:43] And in fact, if you look at SCXML, you're going to see a lot of these things mapped directly to xstate. And that's the secret of xstate, is that xstate is based pretty much completely on this SCXML spec. xstate doesn't invent anything, it doesn't introduce anything new. In fact, it even uses the same algorithms that SCXML uses.
[00:06:08] And so if you're really interested, you could dive in here into the pseudocode, and see how exactly these algorithms work. And so you could see that xstate is complex because there's a lot to learn here, but it is also standardized. It's based on a spec, and it's also compatible with other languages too.
[00:06:33] So Johan says xstate visualization will help for the library to become used more and more, and that's very true. I am working on newer visualizers for xstate, both for dev tools, ones that you can embed anywhere. And also an update to xstate-viz, which is the visualizer used on xstate.js.org/viz.
[00:06:58] So this is using an older version of xstate, and pretty soon, this is going to have an upgraded version. All right, so with all of that said, there's three great resources for you. In fact, there's a lot of resources, but the three that I always point to are the world of statecharts, which is statecharts.github.io.
[00:07:17] The Spectrum community, where you could join and talk about statecharts, at spectrum.chat/statecharts. And also the xstate documentation, which that link is broken. The xstate documentation, which has a lot of really useful resources for you too. So if you go to About > Tutorials, you will see a long list of tutorials, and more are going to be added pretty soon.
[00:08:01] You could just play around and verify that your model of how some logic is supposed to work is actually the way it should work. Kevin asked about xstate 5.0. So with xstate 5, which is coming in a couple months, we're still working pretty hard on it. xstate 5 is going to introduce a major, major simplification.
[00:08:24] First of all, it's going to take the approach that everything is an actor. So the core API of xstate is not going to change by much. Everything is still going to feel pretty much the same. But it's going to be treating actors in a much more simplified way.
[00:08:40] Working with actors in xstate is definitely a big learning curve. And with xstate version 5 it's going to be closer to the pure actor model and strongly influenced by Akka, which is a very popular actor model in Java or Scala. So there's also going to be a size reduction because xstate version 5 is going to be modular.
[00:09:02] If you just need the machine and you don't need the interpreter, you could import just the machine. If you need certain features but wanna leave certain features out, you only need to import exactly what you need. So xstate version 5 is also gonna come with a lot of compatibility between other tools, such as PlantUML and full SC XML support.
[00:09:25] So that you could translate xstate machines to SC XML, and even use those SC XML definitions in any other language or library that supports SC XML.. And you'd be surprised, there's quite a few libraries that support SC XML. There's many other really interesting topics related to statecharts and xstate that are worth exploring.
[00:09:46] Such as automated tests with model-based testing, as well as analysis automatically generating analytics from state transitions. And also being able to predict which states can be traveled to, depending on your user. Also, visualization is a huge topic. There's the xstate visualizer, but xstate is also compatible with many other visualizers out there.
[00:10:14] And yeah, there's also a lot of tools and a lot of different ways that you can integrate xstate into your applications. So I highly encourage you to check them out. And if you are interested in more of these topics, please let me know or let Frontend Masters know, and we will talk about it.
[00:10:33] That is the end of my workshop. I hope that you learned a lot about state machines, statecharts, a little bit of computer science, and xstate. And so I'm really glad that you all were able to attend. And I will be available anywhere on the Internet at DavidKPiano if you want to ask me any sort of question, or just talk about any sort of topic with me.
[00:10:57] I hope you enjoyed it, thank you.