Transcript from the "State Transitions Solution" Lesson
>> And so this is really useful for debugging or just getting a glance at what state is my application currently in as it's running. We also talked about adding the states and transitions into the machine in a very similar way like we did with the previous exercise of having that objects notation.
[00:00:28] So, if we go in here. And we remember that our state machine is supposed to look like this. Where we have a loading, playing, paused state and the loaded, play and pause events. Then hopefully you're getting more used to how to actually add these states and transitions into XState.
[00:00:56] You want an initial state at first, so that's going to be our loading state and then we want to specify all of the states that we have in our state machine which is loading, playing and paused. Now to specify a transition inside the loading state, we put it inside the on object which stands for on this event, we go to this state.
[00:01:26] So on the loaded state, the way that we specify this XState, the full way is by giving it an object with a target of playing. And so what this is going to do is it's going to say if we're in the loading state and the loaded event happens, go to this next target state which is playing.
[00:01:49] Now a shorthand for this is if you have no other actions or things to specify in the object you could just put the key of that state inside as the value instead of the full object. Both ways work both ways are the same. I do recommend you use the object especially if you're going to add actions and conditions, and things like that that we're gonna talk about in the future.
[00:02:23] So in the playing state, on pause, we go to the paused state. And in the paused state, on play- We go to the playing state. Now below you see that we already have the machine being interpreted and we also have the step tools true thing. And I'll show you what that does in a minute.
[00:02:46] But this starts the service so that it could start receiving events. What we also did, and just for the sake of time, it's already done for you. We have a bunch of elements that we could access. And so, we're adding event listeners to each one of them. And so, this is going to be an important pattern using whatever framework that you plan on using with XState, is that the only thing that should really happen inside events listeners is sending an event.
[00:03:17] And so this alone simplifies the implementation of the logic in your application and it also allows you to centralize that logic. So now, when we click a button for instance, all that's doing is being translated to a play events and same thing over here with the pause button, when we click it, that's being translated to a pause event.
[00:03:41] And so we're also subscribing to the state because we do want things to happen on the screen. So, we want the loading button to be hidden if the state doesn't match loading. We want the play button to be hidden. And so now instead of using matches we could do something else.
[00:04:02] Since this play button is based on an event and not the states, we could do it if we can't play. So the state machine does make this obvious where if we're in the playing states then we can't play because that transition is not defined. And so the state.can method allows you to do this pretty easily.
[00:04:26] And say if sending this event is not gonna cause a transition in the state machine, then this is going to return false. Otherwise, if it will cause a transition, it's going to return true. So it is really useful and you could use either dot matches or state.can to control the UI.
[00:04:47] So congratulations. And when we go into the actual application- We see that this pause play, pause play it works. And so, again when you're testing machines or you just want to debug them you could attach the service to the window- And you could send events that way. So, for example, now we can see the loading state and that's because I commented out this loaded event.
[00:05:26] And so if we send the play, nothing's gonna happen. We're still gonna be in the loading state. And that's because we haven't loaded the data yet. So, if we instead send loaded now that changes to the plays states, and I know it confused me before in the past but showing the pause button means it's in the played state because it shows like, okay, you could pause it because it's playing.
[00:05:57] So you could click pause, and now it's in the play state, pause state, play, etc. So if your app in this file looks like this and it behaves like this, then it's working. So congratulations. And so this is really useful for debugging or just getting a glance at what state is my application currently in as it's running.
[00:06:25] And so this is really useful for debugging or just getting a glance at what state is my application currently in as it's running. So you could import inspect from XState inspect and then give it a couple of options. By default it's gonna try to find an iframe and this option might be changing in the future or this default might be changing.
[00:06:50] And we also wanna open it up in stately.ai/viz?inspect. And so what this is gonna do is it's going to visualize our machine as it is running in the app. And so this is what we call inspecting the state machine. So right now we see that it's in the loading state.
[00:07:10] And so this is really useful for debugging or just getting a glance at what state is my application currently in as it's running. [COUGH] So we can press pause to pause it. And now we see it's in the paused state, but one cool feature about this inspector is that it goes both directions.
[00:07:30] You could also click play over here and cause the machine to be playing. So it's bi directional, it's going to work both ways. And so this is really useful for debugging or just getting a glance at what state is my application currently in as it's running.