Diagramming a State Machine

[00:00:00]
>> So let's refactor this a bit more, and actually create a state machine. One of my favorite tools for doing this is actually called excalidraw. And excalidraw is great, because I'm gonna put this on night mode, because you could easily draw these shapes and everything. So I could have a little rectangle here, and basically create a state.

[00:00:25]
So let's talk about our alarm component for a minute. At first, it's in the inactive states, right? Now, it could also be in the pending states. And that's when we're waiting for it to save or do whatever it needs to do. And finally, after pending, it could go to the active states.

[00:00:48]
Now looking at this, you might think, okay, we described all the states that our component can be in, are we done? Not exactly, because we want to not only specify the states in our application, but also how those states can change. Basically how we can transition from one state to another state.

[00:01:09]
So we know that from inactive, we could go directly from inactive to pending. And we could also go from pending to active. And we could go from active to inactive. So notice there's no arrow going directly from inactive to active. And so we need to not only define the logic for what each of these three states should do, but we should also define the logic for how those states can move between each other.

[00:01:43]
Now, I'm also going to note this circle and arrow, to show that this is the initial state. So at first it's inactive, it goes to pending, goes to active, and then it goes to inactive. But there's one more thing. How exactly does it go from inactive to pending to active?

[00:02:02]
We saw in our original components that we were setting each one of the states directly. So we would set status to active here, set status to inactive here, set status to pending here. Now while this does technically work, it doesn't give us a clear picture of the logic of our components, basically what's happening in each of these arrows.

[00:02:26]
So to fix that, we need to define events. We basically need to define what should the next state be when something happens. So I'm going to say over here inactive depending should happen when we have some sort of toggle events. And then pending to active should happen after some sort of success events.

[00:02:50]
Basically if it's saved, if we successfully set the alarm, and only then, can we transition from pending to active. And again, if we toggle, we should go from active to inactive. Now what we just made is called a state machine. And this state machine, like you might have seen in the first course, is made up of a few parts.

[00:03:16]
We have our finite states, which are the states that define basically the only possible states that this component can be in. And we have each one of our events, which is either toggle or success. And we have transitions that say, when we're in the current states, and an event happens, now we should be in this next state.

[00:03:37]
And so you could show this to anyone, even someone who's non-technical. And they're basically going to understand the general flow, whether it's a user flow or a logical flow of any one of the components of your system just by looking at something like this.