I 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.
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.