the 'in' guard works only if the state is defined by a complete path or a 'custom' id but it should work also with relative path

[jbouecke]

Description
If a transition is guarded via an 'in' property, the state that is referenced there cannot be addressed in the same way the 'target' is addressed. This isn't documented and also no good behaviour.

Expected Result

If the state in the transition that the machine must be 'in' is rerenced via a 'custom' id, it works, if it is referenced with a 'complete' path (including top level state 'name'), it also works, but not if it is referenced via relative path like it is usually done for 'target'.

Actual Result

There is no error, but the guard is just 'never' passed.

Reproduction

see the following machine definition:

createMachine({
  id: "example",
  initial: "TopeLevelState",
  states: {
    TopeLevelState: {
      type: "parallel",
      states: {
        EFFECTED_STATE: {
          states: {
            A: {},
            B: {},
            C: {}
          },
          on: {
            A: {
              target: "EFFECTED_STATE.A",
              in: "STATE.B"
            },
            B: {
              target: "EFFECTED_STATE.B",
              in: "#SB"
            },
            C: {
              target: "EFFECTED_STATE.C",
              in: "TopeLevelState.STATE.B"
            }
          }
        },
        STATE: {
          initial: "A",
          states: {
            A: {
              on: {
                B: "B"
              }
            },
            B: {
              id: "SB",
              on: {
                A: "A"
              }
            }
          }
        }
      }
    }
  }
});

• XState Visualizer
• observable notebook

Additional context

I stumbled accros this while trying to enhance the visualizer to not show forbidden transitions as active (see this pull request)

[davidkpiano]

This behavior is changing in v5 to avoid confusing behavior, where there will be stateIn(...) guards that work like state.matches(...).

Additionally, for v4, in: ... guards are relative to the parent parallel state or with an ID. All state nodes have an ID which is the state node's path:

in: '#example.TopeLevelState.STATE.B'

[jbouecke]

I understand that, but wouldn't it be nice to refer the states in the same way as you can refer target states?
If I get you right, the behaviour in v5 will be again working just with id's or complete path?

[davidkpiano]

If I get you right, the behaviour in v5 will be again working just with id's or complete path?

It will expect either the ID or the complete path: https://github.com/statelyai/xstate/blob/c34a858c122dc5d6463e2a7643921c638ba15d1a/packages/core/test/stateIn.test.ts