Can the state machine ignore unhandled events instead of generating a transition for each event?

[haocheng6]

For example, if my state machine is defined as follows:

const testMachine = Machine({
  id: 'test',
  initial: 'running',
  context: {
    retries: 0
  },
  states: {
    running: {
      on: {
        STOP: 'idle'
      }
    },
    idle: {
      on: {
        START: 'running'
      }
    }
  }
});

When the machine is at the running state and receives a START event, it still generates a transition from running to running. I understand I can use state.changed to filter out those meaningless transitions, but what if the state machine is defined as follows:

const testMachine = Machine({
  id: 'test',
  initial: 'running',
  context: {
    retries: 0
  },
  states: {
    running: {
      on: {
        STOP: 'idle'
      }
    },
    idle: {
      on: {
        START: 'running',
        STOP: 'idle' // Please note this.
      }
    }
  }
});

Now I want to allow explicit idle->idle transitions but still don't want running->running transitions.

I used to use SCION. It never generates a transition when an event cannot be handled by the current state. Can I do that with XState?

[Andarist]

Could you describe your issue in more detail? What do u have in mind by generating transitions? XState should not transition away from running upon receiving START

[haocheng6]

If I add the following code:

const testService = interpret(testMachine).onTransition((state) => {
  console.log(state.value);
});

when the state machine is at the running state and receives a START event, a new line of running will be output in the console, which is what I want to get rid of.

As I mentioned before, I don't want to simply check state.changed before logging as follows:

const testService = interpret(testMachine).onTransition((state) => {
  if (state.changed) {
    console.log(state.value);
  }
});

because I want to differentiate the following two cases:

1. the new event is not handled by the current state and the state stays unchanged;
2. the new event triggers the state machine to transition, but the destination state is the same as the orgin state.

I wonder if I can differentiate those two cases in the onTransition function.

[davidkpiano]

That makes sense - the machine did not transition, so intuitively, the onTransition handler should not be called.

Note to self - two breaking changes we can make to .onTransition(...) in v5:

1. Should only be fired on transitions, and not with the current state when the machine starts (which is the current behavior)
2. Should not be fired when the machine doesn't transition

The only downside big change is that (besides not getting the handler called) you do not get the latest event that was sent to the machine. But .subscribe(...) can cover that use-case.

I think the big difference between .subscribe and .onTransition in v5 will be:

• .subscribe is called with latest state changes
• .onTransition is called with transitions

So in v5, an unhandled event would technically be a "state change" (as far as the interpreter is concerned) because .event changes, but it wouldn't be a transition.