Skip to content

Event destination state should be state dependent #25

@kurige

Description

@kurige

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:

inbox

All of the events have a single destination state, regardless of the current state. So, the following state machine is currently impossible to model:

complex_inbox

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 }];

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions