onDone dynamic target

[hosseind88]

is it possible that we access to context on onDone? I mean like this:

onDone: {
    target: (context) => context.nextState
},

[Andarist]

Dynamic targets are not supported right now.

This is something that often comes up - I wonder if it's possible to support this, maybe in some kind of a constrained way. We still need to be able to know where a particular transition can go and allowing "it can go anywhere" seems like something that we'd usually like to discourage. OTOH there are some rare occasions when smth like this would be useful. And, of course, this poses some interesting questions like - how something like this should be visualized?

[davidkpiano]

If we want these machines to be mathematically sound (*), transitions of the form of:

(state, event) => nextState

must fit the following criteria:

• The transition function must be deterministic (i.e., a pure function)
• All transitions should be known
• There should be a finite number of transitions

Having a data-structure-based API like this:

on: {
  EVENT_1: 'one',
  EVENT_2: [
    { target: 'two', cond: 'something' },
    { target: 'three' }
  ]
}

fulfills those criteria, because we can iterate through the on: { ... } object and know all of the possible transitions.

But an API like this:

on: {
  EVENT_1: (ctx) => {/* ... */}
}

does not fulfill the criteria, because:

• There is no way of determining nor enforcing that the function is deterministic (or it's very difficult)
• There is no way of knowing all the possible targets and how those targets can be determined
• Therefore, there is no guarantee that the number of transitions is finite (can have infinite combinations of conditions/actions, despite finite states)

So, some sort of a middle-ground API like this would have to be done instead:

on: {
  // pseudocode
  EVENT_1: specialTransitionObject({
    getTarget: (ctx, e) => {/* ... */},
    getAllTargets: (ctx, e) => {/*
      returns array/iterator of all possible transitions
    */}
  })
}

But then, that is not serializable, and isn't easily visualizable. We're still thinking about how this can work, because there are valid use-cases, especially for routing.

* The reasons that mathematical soundness is important here is so that we can generate a directed graph of all possible transitions, which makes visualization, path generation for testing, static analysis, etc. possible.