3 ms·
Statecharts: Some Critical Observations (2004) [pdf]
- sktrdie 7y agoI agree with some of the criticisms even though I'm not 100% familiar with all variation of the statechart semantics. I use xstate and it works pretty well for all my use cases. One important thing to note is that statecharts is just a specific runtime. So it compiles down to code - that code just runs the same way you'd expect any other code to run. Main differences is that it's mainly event-driven and that you execute functions only in response to the statecharts changes - but at the end of the day you're still just executing functions. A very simple example is: doorOpened -> ringBell() ringBell() is only called when the door is opened. What statecharts adds is simply an extra level of indirection where instead of being event -> action(), it's event -> state -> action(). Meaning that the state is always checked before executing a function: doorOpened -> opened -> ringBell() This is crucial because emitting doorOpened again may yield different results based on the state of the chart! Let's emit it again: doorOpened -> closed -> keepDoorOpen() This extra level of "check" before executing functions may seem trivial but opens the doors to designing quite complex event-driven reactive behavior using a drawing! Quite powerful stuff.
- guykdm 7y agoAll kinds of logic is hierarchical. Some use cases are mutually exclusive, which translates to them being nested under different states.
- deleted 7y ago[deleted]