Transcript from the "Modeling States" Lesson
>> When designing state machines, obviously they're not going to be as simple as that all the time. If you are, number one, you're lucky, number two, you might not need a state machine for something as simple as that, where maybe even one boolean might suffice. So let's take this for example.
[00:00:17] Just in terms of how you would structure your states and how you would structure your events, let's say that we're designing a feedback form. The first screen is going to say, How is your experience, and the user could click Good or they could click Bad. When they click Bad, it brings you to a form that asks you why.
[00:00:34] And in this form, you could submit, and it takes you to, Thanks for your feedback. When you click Good, since we just assumed that you had a great experience and we don't need you to tell us why, we just take you to, Thanks for your feedback. And on any of these screens, when you click the x, or you click the Close button, you should transition to a closed state.
[00:00:55] So there was a question in the chat about how you would name these things, how you would name states and events, and so that's a really good question. But first, let's talk about how we would design or model the state machine in the first place. So we have our initial state, which is question, and we first want to add the states.
[00:01:15] That's the first thing you should do. You should think about, what modes or states or behaviors should my application be in at one given time? So only one state at a time. And in this case, we could only be in the question, the form, the thanks, or the closed state, at any given time.
[00:01:36] After that we could start filling in events. And so we have to think about, what could possibly happen in this app? What could the user do or click or submit? Or what external events might come in that might change the states? So in the question state, we had two options.
[00:01:54] We could either click Good, which will take us to the, thanks state, or we could click Bad, which will take us to the form states, and so we have it here. And then same thing as described before. When we have these submit events, we go from form to thanks.
[00:02:08] And on the close events, we go from thanks to closed. And of course, in the closed state, this is known as a sync node, which means that nothing can happen after it's closed. Obviously, you can't reopen the feedback form. And if you can, you would model that explicitly in your logic.
[00:02:30] So then after that, of course, we add the transition function and we track the current states. We receive events, just like we did in the exercise. And we use that to interpret the machine. So let's talk about interpretation a little bit more. What we were doing before, when we were interpreting this machine, is we have this floating mutable variable over here called currentState.
[00:02:57] Now, this isn't exactly what we might want. Instead, we might want to keep this in an interpreter. And so when we have a function interpret, we could keep that current state inside of a closure. And so that way we could define our send function right inside. And internally, it's going to update the current states.
[00:03:21] And then we could expose this send function right over here. So this gets a little more advanced, but once you start thinking about how different things can interact with this interpreted machine, you have to consider things like listeners. So we might have an onTransition method which says, if we get a listener add it to the set of listeners, and whenever we get a new state, we wants to send that current state over to the listener.
[00:03:57] And so that's done inside of send. But then we also have to think about what's currently happening inside of our inside of our interpreter and its lifecycle, like when it could start, when it could stop. So because we have listeners, eventually when we're no longer using machine, we have to clean it up.
[00:04:19] And so that's what this stop method is for over here.