The Rise of the State Machines
smashingmagazine.com
The Rise of the State Machines
1–10 of 17 posts
Re: The Rise of the State Machines
#2Lol, i have been thinking about implementing this for the ordering logic in my own shop platform ( handling, opening, refunding, partial delivery, paid, ...).
But this article also describes how the data handling is processed, which seems to be totally different from what i was thinking about
Re: The Rise of the State Machines
#3State machines are wonderful for testing as well. Any time you have a bug, just record the events that got you into the buggy state, and replay it in a test.
Re: The Rise of the State Machines
#4State machines are wonderful for testing as well. Any time you have a bug, just record the events that got you into the buggy state, and replay it in a test.
State machines are wonderful in general. I'm sure most people were taught it, but somehow it always seems more complicated than just to code some if-statements... until you have some spaghetti
logic with many transitions which is magically made maintainable and less buggy by refactoring it into a state machine.
That's how state machines first clicked for me, and it blew my mind. And this keeps happening, when somebody mentions it in code review, somebody's mind is usually blown.
So the more people read about this "boring" subject the better. Although the (non)deterministic finite automata (DFA/NFA) regex engines are a super interesting read IMO: https://swtch.com/~rsc/regexp/regexp1.html
Re: The Rise of the State Machines
#5I remember wondering if foregoing the front end frameworks and using a simple state machine - such as the type I remember making for compsci assignments - would actually make things easier. But then I thought "well I'm new to front end, surely if this was a good solution to the problem everyone would be doing this and there wouldn't be a cambrian framework explosion".
I'd love to hear if others have tried using a state machine.
Re: The Rise of the State Machines
#6Congrats JS community on inventing the wheel.
Re: The Rise of the State Machines
#7I wrote a game for mobile devices in JavaScript that used a state machine and it worked far better than I could have imagined. It surprises me that there isn't a good web framework that does something similar, though Angular's notion of states comes somewhat close.
Re: The Rise of the State Machines
#8Couple of questions/comments/nitpicks about the article:
- does the turnstile example in the article actually need a state machine? When you insert a coin it unlocks, when you push it locks. No need to remember the state you are in.
- in the data-fetching example, it says that in the "fetching" state it is not /accepting/ any clicks. But then shouldn't this be explicitly specified in the state machine, by having the click event loop back into the fetching state? I think it would be less error-prone and more systematic to account for all the events in all the states.
Re: The Rise of the State Machines
#9I remember wondering if foregoing the front end frameworks and using a simple state machine - such as the type I remember making for compsci assignments - would actually make things easier. But then I thought "well I'm new to front end, surely if this was a good solution to the problem everyone would be doing this and there wouldn't be a cambrian framework explosion". I'd love to hear if others have tried using a sta…
If you google "finite state machine javascript", you'll see that lots of people have given it some thought, but it never seems to catch on. My theory is that state machines aren't a natural way to think about most problems nor are they a natural solution to most UI/frontend dev problems. Button states are a natural fit for state machines because they have a finite, well defined and well understood number of states. But, because of that, we already have the equivalent state machine built directly into CSS3 in the form of selectors (:hover, :disabled, :focused, etc).
Re: The Rise of the State Machines
#10Another similar article: https://css-tricks.com/robust-react-user-interfaces-with-fin... (full disclosure, I wrote this)
There is definitely a learning curve to state machines, and even more so with statecharts/UML. It's much, _much_ easier to start coding an application from a bottom-up approach (start coding, colocate app logic wherever it's needed, refactor later) than a top-down approach (systematically plan the entire higher-level behavior of your app's various parts before writing a single line of code). That's why it's slow to catch on in the application development (web + native) part of the tech world.
However, in game development, hardware development, etc. state machines and statecharts are more commonly used. To me, the ability to declaratively structure your program's behavior as a directed graph opens the door to the possibility of being able to automate integrated tests (simple path/shortest path/etc. algorithms), statically analyze logic (are all states reachable? are all events handled?), optimize paths, add and remove features without worrying about if some other part of the application will be adversely affected, have smarter analytics, visualize app state, and much much more.
I know there's critics to FSMs where other more idiomatic language-oriented approaches would suffice (I myself absolutely detest the OOP state pattern - it's a needlessly imperative, hard-to-analyze state machine), but I think if developers further understood and saw benefits to functional, declarative, reactive programming and statecharts (a huge improvement over conventional FSMs), application development as a whole could reach a new level of efficiency and robustness.