The behaviour to be implemented and passed to use Finitomata to receive
all the state transitions notifications.
Modules and processes
The listener: option accepts either an implementation of this behaviour, or anything
send/2 accepts (a pid/0, a port/0, a registered name, or a
{:via, module, term}/{name, node} tuple.) The two are told apart by whether the
given term is a module exporting after_transition/3; a process receives
{:finitomata, {:transition, state, payload}} (and
{:finitomata, {:fork_error, state, error}}) messages instead of a callback invocation.
Because a registered name is an atom too, the distinction is only meaningful for a
loaded module: function_exported?/3 answers false for a module that has never
been reached, which is the normal state of affairs in a freshly booted release or at
the very beginning of a test run. Finitomata therefore ensures the module is loaded
before deciding, so a lazily-loaded listener module is never mistaken for a process
name (which would raise inside the transition and take the FSM down with it.)
No explicit Code.ensure_loaded!/1 call on the listener is needed on the consumer side.
Summary
Callbacks
To be called when a Finitomata.on_fork/2 resolution fails.
To be called after a successful transition
Callbacks
@callback after_fork_failure( id :: Finitomata.fsm_name(), state :: Finitomata.Transition.state(), error :: any() ) :: :ok
To be called when a Finitomata.on_fork/2 resolution fails.
Optional callback; implement it to be notified when the FSM reaches a fork state but the
fork cannot be resolved (an unknown/ambiguous/missing fork target, a bad return, or a
raise). state is the fork state and error is the resolution failure reason.
@callback after_transition( id :: Finitomata.fsm_name(), state :: Finitomata.Transition.state(), payload :: Finitomata.State.payload() ) :: :ok
To be called after a successful transition