Internal events don’t have specific names; the events themselves are generated automatically by the statechart. However, sensing (reacting to) an event is done by way of transitions that specify events such as
in (somestate) ———————————————————————>
entered (B) ———————————————————————>
When processing an external event, the statechart might go from state A to state B; this state change can “generate” new events such as
- We’re no longer ‘in’ state A
- State A was exited
- State B was entered
- We’re now ‘in’ state B
Immediately after a state transition happens (and importantly before the next external event is processed), the state machine checks if any transitions get “enabled” by any such internal events. If there are any, then they are considered triggered by an internal event, and those transitions happen immediately.
When a statechart defines an activity or otherwise invokes a service, it can also declare the effect of the completion of the activity or service.
In SCXML, the
In(state) conditional expression that can be used in guard functions. Technically, this is not an event, but such a guard ends up being evaluated whenever a state transition happens.
SCXML also specifies a number of events that are generated by the execution of a statechart:
done.invoke.<ID>event is generated whenever an invoke completes.
XState natively supports
in: 'state' guards defined on the transition. Technically, this is not its own event, but rather a side effect of a state transition.
XState also supports