Javascript: State Machine

01/29/15

As I've been thinking about how to modularize my timer, I've come to realize that I probably want to learn how to implement the State Pattern in javascript. I'm sure there's already good tutorials online for doing just that, but I'm going to take a whack at it for the length of the bus ride home before I look up how to do it properly.

What I want is to alter the object when a state-change function that it owns is called. I wonder if there's a simple way to overload an object's members with a prototype object or something like that. That's something I'll be willing to look up while trying this out (though, I'll probably explore javascript stuff via node for a bit first, as I won't have Internet connection on the bus anyways).

Now, you may be wondering, why do I need a state machine? Because a paused timer and a running timer functionally quite different, I feel, and coupling the two things together as one thing maybe isn't necessary. The running timer needs to know when it expires and when to notify the user of certain distances to the expired time. The paused timer just needs to know how much time is remaining. In switching states, the paused timer will convert the remaining time to a specific expired time, and the active timer will convert the expired time to a remaining time value. Notification stuff will need to be saved in some way, as well.

So, basically, the timer will have the same interface regardless of state, but how it's running will be different based on the state it is in. And I'm wondering how much I can separate the two functionalities.

Though, perhaps at first it would be better to pseudo-state it. Meaning, I will save a variable called "state", and just save that variable as a string that switches between "PAUSED" and "ACTIVE", and make actions different in each significant function using a simple switch block.

I should learn a more complicated and modular means of doing that, but it can come later. I should focus on functionality and learning to do just enough good design to make improvements to code without having to start over. But for right now, starting over is probably what I'll do, and I think I'll infer better design practices each time I consider it valuable enough to start over.