
Statecharts: Some Critical Observations (2004) [pdf] - luu
https://mbreen.com/breenStatecharts.pdf
======
sktrdie
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.

------
guykdm
All kinds of logic is hierarchical. Some use cases are mutually exclusive,
which translates to them being nested under different states.

