What signals does the machine accept given the current state?
ikitommi opened this issue · comments
XState has an api to ask which signals are allowed given the current state:
const { initialState } = lightMachine;
console.log(initialState.nextEvents);
// => ['TIMER', 'EMERGENCY']
This is really important as this information can be used to enable/disable & hide/show action buttons on uis based on their current availability.
I propose clj-statecharts to have a function of machine state -> State
, e.g.
(def fsm
(fsm/machine
{:id :nested
:initial :a
:on {:top {:target :a
:meta {:ui {:text "restart"}}}}
:states {:a {:on {:a {:target :a
:meta {:ui {:text "nada"}}}
:b {:target :b
:meta {:ui {:text "goto b"}}}}}
:b {:on {:c :c}}
:c {:on {:c :c}}}}))
(fsm/next fsm (fsm/initialize fsm))
;{:top {:target :a
; :meta {:ui {:text "restart"}}}
; :a {:target :a
; :meta {:ui {:text "nada"}}}
; :b {:target :b
; :meta {:ui {:text "goto b"}}}}
I can see the rationale, but atm I myself doesn't have a use case for that. So patches welcome.
Some considerations:
- allowed transitions could be from either the leaf state itself, or any of its ancestors.
- for transitions withs guards, the guard is going to be evaluated, but I guess this is fine since guards are for most of the time are just pure functions of current state.
Thanks. I added this into my preprocessor for clj-statecharts, I can now enrich and precompute things I need, so not in an urgent need of this now at library level. If you want to close this, ok for me. Happy to do a PR at some point, when needs and impls have setteled. Cheers.
e.g. have a protocol to both hide the impl and add missing things. Not doing much yet and not sure where it evolves from here.
(defprotocol FSM
(-id [this])
(-initial [this])
(-states [this])
(-next [this state])
(-form [this])