You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This might not seem benefitial at first, but would be a huge help, when using the event dispatcher. It would enable having nifty listeners such as listening to confirm transitions and sending e-mails regarding the state change. No explicit listing of transitions would be necessary.
BC can also be kept by simply keeping support for the old structure.
Would you be interested in having this merged, should I implement it?
The text was updated successfully, but these errors were encountered:
Without having read this first, I wrote the Pr because I can't port the state machine for the Kinesis driver without it. The syntax used is identical, I think.
I think it's a good idea!
Especially, it would be great to add different guards for some variants of using same transition, so the machine could change to the state accordingly guard with true result.
Currently all transitions must be uniquely named. There's support to allow a transition to go from multiple states to a single end state, i.e.:
I propose adding support to have transitions going to different states, but having a same name, i.e.:
This might not seem benefitial at first, but would be a huge help, when using the event dispatcher. It would enable having nifty listeners such as listening to
confirm
transitions and sending e-mails regarding the state change. No explicit listing of transitions would be necessary.BC can also be kept by simply keeping support for the old structure.
Would you be interested in having this merged, should I implement it?
The text was updated successfully, but these errors were encountered: