Currently action()s only have the context record available as it was at the time the action was invoked. However, some actions, especially longer running ones, may want to send events back to the FSM. This happens when the FSM should continue its regular behaviour (in my case: coordinating the state of the UI) while the asynchronous/long running action does its work and sends events (i.e. data) to the FSM. This is especially a problem when multiple instances of the FSM are active at the same time and therefor a "singleton" pattern won't work to identify the FSM to send the events to.
The solution here could be to provide not only the context, but also the "send" function as an argument to the action function.
Currently
action()
s only have the context record available as it was at the time the action was invoked. However, some actions, especially longer running ones, may want to send events back to the FSM. This happens when the FSM should continue its regular behaviour (in my case: coordinating the state of the UI) while the asynchronous/long running action does its work and sends events (i.e. data) to the FSM. This is especially a problem when multiple instances of the FSM are active at the same time and therefor a "singleton" pattern won't work to identify the FSM to send the events to.The solution here could be to provide not only the context, but also the "send" function as an argument to the action function.