Manual transition where the target is based on the event

[bennyKY]

Hi, we have a machine that currently all transitions might happen. I.e:

{
    id: 'letters',
    initial: 'a',
    context: {},
    on: {
      MANUAL_TRANSITION: ???
    },
    states: {
      a: {},
      b: {},
      c: {},
      d: {},
      e: {},
      f: {}
    }
  }

As you can see the events are in the root level of the machine.
When a MANUAL_TRANSITION event is received (e.g { type: 'MANUAL_TRANSITION', target: 'b' }) so the machine need to transition to b state (event.target). If { type: 'MANUAL_TRANSITION', target: 'e' }received it need to go to e state.

Is this behaviour can be achieved? Other alternative is to create an event for every possible state:

on: {
  a: 'a',
  b: 'b',
  c: 'c'
  ...
}

but that doesn't sounds right.

[Andarist]

This is not possible this way - u cant have dynamic targets. All transitions have to be statically defined so then can be visualized etc. Not knowing what problem you are trying to solve makes it harder to suggest viable alternatives.

[aslaker]

Very late to this conversation, but figured I would post here for anyone else looking to solve this. As @Andarist mentions above, dynamically adding these events during runtime is definitely the best solution. I was able to get this working properly for a previous client, by using a configuration object that held the possible states and then the states and events were dynamically generated at runtime and added to the machine definition.

[davidkpiano]

Thanks for your input, @aslaker. I've also been thinking about the idea of "routable states" that would provide root-level implicit transitions to them:

// PSEUDOCODE
const machine = createMachine({
  // ...
  states: {
    here: {
      // same as adding a root transition:
      // 'xstate.route.here': { target: '.here' }
      route: true
    },
    // ...
  }
});

const actor = interpret(machine).start();

actor.send(routeTo('here'));
// state.value is now 'here'

[aslaker]

@davidkpiano That looks interesting! Seems like a much smoother experience than needing to generate the different states and events based off of a config.

My use case is a multi-part form flow that has events for NEXT and PREVIOUS set on each state node, but there is also a stepper that allows you to traverse to any point in the form which is why the manual transition was needed.

This seems like a much cleaner proposal than what I was doing. Thanks for sharing!

[rlueder]

Just landed here and have the exact same use case as @aslaker, a multi-step checkout form stepper with NEXT and PREV that should allow users to navigate to previous states as needed.

[dschwarz-brex]

Also landed here with the same NEXT/PREVIOUS use case, needing unique state machines and transition logic for each step. @aslaker's solution with generated transitions sounds promising? Am thinking of doing something like:

on: {
  next: [
     {
        guard: { type: 'isNextStep', params: { step: 'step1' } },
        target: 'step1',
     },
     {
        guard: { type: 'isNextStep', params: { step: 'step2' } },
        target: 'step2',
     }
  },
},
...
   guards: {
      isNextStep: ({ context }, params) => {
        return (
          context.steps[context.steps.indexOf(context.currentStep) + 1] == params.step
        );
      },
    },

[davidkpiano]

This seems like a contrived example, but generally speaking, when you want a "dynamic state" based on the event, that's a sign that that state isn't really a finite state, but more of an extended state (belonging in state.context).

However, if you really want to do this, and you do have a finite number of states, build it out:

const states = ['a', 'b', 'c', 'd', /* ... */];

const createSomeMachine = () => {
  return createMachine({
    // ...
    states: states.reduce((acc, key) => {
      acc[key] = {};
      return acc;
    }, {}),
    on: {
      MANUAL_TRANSITION: states.map(state => {
        return { target: state, cond: (_, event) => event.target === state }
      })
    }
  });
}

[bennyKY]

Thanks a lot!

[H1D]

Faced same necessity. What I came up with is to use raise which can raise different events based on event/context.