-
Notifications
You must be signed in to change notification settings - Fork 129
Open
Description
As I understand it, events in TransitionKit can only have a single destination state. This is a result of the set of valid event transitions being state-independent, rather than a function of the current state.
As an example, here's the state machine from the README:
All of the events have a single destination state, regardless of the current state. So, the following state machine is currently impossible to model:
Well, not impossible. You can create two "View Message" events, two "Mark as Unread" events, and two "Delete Message" events... And then fire the correct one in a if/else if block by checking the current state. But that quickly becomes unwieldy in a larger state machine.
- Is my understanding correct that this is a limitation of the current API?
- Is this something that you would be willing to accept a pull request for, or is this part of the design that you wouldn't be open to changing?
- If you are open to a pull request, how open are you to API changes? The API will have to change, but hopefully not too much. Something along the lines of:
TKState *S1 = [TKState stateWithName:@"S1"];
TKState *S2 = [TKState stateWithName:@"S2"];
TKState *S3 = [TKState stateWithName:@"S3"];
// Simple transition
TKEvent *simple = [TKEvent eventWithName:@"Simple Event" transitioningFromStates:@[S1, S2] toState:S3];
// Add more transitions to existing event
[simple addTransitionFromStates:@[S3] toState:S1];
// Or add them all at once
TKEvent *complex = [TKEvent eventWithName:@"Complex Event" transitions:@{ @[S1, S2]: S3, @[S3]: S1 }];Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels

