6 ms·

Here's a tip for state machines. If you've got a transition that takes some time then you often actually need another state to represent the state that the syst

Here's a tip for state machines. If you've got a transition that takes some time then you often actually need another state to represent the state that the system is in during the "transition". This is usually modeled better on backend systems (a state while waiting for a network response to arrive) but is often modeled poorly in front-end systems (a state while waiting for an animation to finish).

Klathmon 9y ago
This is one of the reasons why I love ReactJS. You quickly realize that it just won't work unless you model all of those states in your component. And the act of "forcing" you to model all of those states often catches logic bugs or issues that wouldn't have been found until much later in the process.
- blaqkangel 9y ago
  And that's exactly why I'm loving Elm right now. The compiler is also incredibly helpful in finding out where you might have missed a state.
HeyLaughingBoy 9y ago
This is something I had to deal with pretty recently. The sequence I needed to model was: Operator pushes Start Turn motor on Motion triggers switch to ON state Motion triggers switch to OFF state Turn motor off Machine changes state to RUNNING The time between pushing Start and RUNNING is only a couple seconds, but there's a chance that something could jam, the switches could fail, or something I have no knowledge of could go wrong. Question becomes, do I now need an intermediate "In Motion" state for the six or so cases where this happens? In the end, I decided no, because there was no other transition out of that state than the expected behaviors, so modeling the intermediate state didn't offer me any benefit[1]. Failure to get to OFF state within a certain time puts the system into a global error condition that required manual intervention to fix. I don't have a real comment here :-) other than to back up your point that modeling isn't as obvious as it first appears to be. [1] I would have created this intermediate state if this was a complex controller that was likely to have new rules added later. However, knowing it was a simple one-off, I'd just be giving myself extra work for no benefit if I did it now.
- lfowles 9y ago
  I prefer having nominal intermediate states just for debugging purposes. "What am I doing now? Does being in START imply it's already started the process? Does being in RUNNING imply the process was completed successfully?" vs "What am I doing now? In motion!" In the example given, I'd probably stick to a single intermediate state and let the language work as my implicit state machine for the internals. Depends a lot on the boilerplate required to insert states though, my preferences owe a lot to the HFSM implementations I've used in the past.
- richdougherty 9y ago
  I think it's fine to leave out these states so long as you're conscious of what you're doing and you've thought about it. A lot of people don't even realise they've made a modeling error. Then you invariably see code written to try and handle "unexpected errors".

Klathmon 9y ago

This is one of the reasons why I love ReactJS. You quickly realize that it just won't work unless you model all of those states in your component. And the act of "forcing" you to model all of those states often catches logic bugs or issues that wouldn't have been found until much later in the process.

blaqkangel 9y ago
And that's exactly why I'm loving Elm right now. The compiler is also incredibly helpful in finding out where you might have missed a state.

HeyLaughingBoy 9y ago

This is something I had to deal with pretty recently. The sequence I needed to model was: Operator pushes Start Turn motor on Motion triggers switch to ON state Motion triggers switch to OFF state Turn motor off Machine changes state to RUNNING The time between pushing Start and RUNNING is only a couple seconds, but there's a chance that something could jam, the switches could fail, or something I have no knowledge of could go wrong. Question becomes, do I now need an intermediate "In Motion" state for the six or so cases where this happens? In the end, I decided no, because there was no other transition out of that state than the expected behaviors, so modeling the intermediate state didn't offer me any benefit[1]. Failure to get to OFF state within a certain time puts the system into a global error condition that required manual intervention to fix. I don't have a real comment here :-) other than to back up your point that modeling isn't as obvious as it first appears to be. [1] I would have created this intermediate state if this was a complex controller that was likely to have new rules added later. However, knowing it was a simple one-off, I'd just be giving myself extra work for no benefit if I did it now.

lfowles 9y ago
I prefer having nominal intermediate states just for debugging purposes. "What am I doing now? Does being in START imply it's already started the process? Does being in RUNNING imply the process was completed successfully?" vs "What am I doing now? In motion!" In the example given, I'd probably stick to a single intermediate state and let the language work as my implicit state machine for the internals. Depends a lot on the boilerplate required to insert states though, my preferences owe a lot to the HFSM implementations I've used in the past.
richdougherty 9y ago
I think it's fine to leave out these states so long as you're conscious of what you're doing and you've thought about it. A lot of people don't even realise they've made a modeling error. Then you invariably see code written to try and handle "unexpected errors".