Will strict mode really be removed? & Implications and use cases

[mellanslag-de]

I found the discussion of the removal in 2020 and the PR to remove the strict mode.
And also strict mode isn't mentioned any more in the official docs. References still exist, but they lead nowhere.

I guess this really means that strict mode will be gone in v5?

I'm sad about this because #1 I liked it at least in dev mode (though that could still be possible in the future?).
Because that way I could immediately see if I have a bug in my UI, e.g. if a close-button is still clickable, even though it shouldnt because the popup is already closed, and the state machine doesnt accept it any more. That would be a UI bug thats hard to spot without xstate telling me, at least for more complex cases.

And #2 I was starting to think about a combination of XState and rxJS, where I use XState to define&document the the valid order of events that may be sent over a rxJS stream. An interception function would then send any event to XState, see if it throws an exception, and if not, pass the event on to the rxJS stream/observable.
I know its kind of not the purpose of XState, there are many limitations and edge cases not working, but I also see the huge advantage of clarity the combination offers.
In this case hiding strict mode behind the dev flag seems bad because I need it even in production use.

So, final questions:

1. Is strict mode going to be removed?
2. Is there maybe another way to check if a state transition was successful, so that the 2 use cases stay possible?

Thanks in advance!

[davidkpiano]

The mode itself is removed in v5, but you can be explicit about its same behavior by using a root wildcard transition, which actually lets you be more flexible with strictness:

const machine = createMachine({
  // ...
  on: {
    '*': {
      actions: () => { throw new Error(...) }
    }
  }
});

[dr-skot]

Does this work though?

I'm finding that the action fires but the error isn't thrown by actor.send()

export const machine = createMachine({
  on: {
    "*": {
      actions: () => {
        console.log("Unknown event");
        throw new Error("Unknown event");
        console.log("I threw an error");
      },
    },
  },
});

it("throws when I send an unknown event", () => {
  const actor = createActor(machine).start();
  expect(() => actor.send({ type: "GOBBLEDEGOOK" })).toThrow();
});

console.log
    Unknown event

Error: expect(received).toThrow()

Received function did not throw

[dr-skot]

Another problem with { on: "*" } is it breaks can()

actor.getSnapshot().can({ type: "UNKNOWN" })) // === true

[davidkpiano]

What is your goal? Do you want to prevent unknown events from being sent during development or runtime?

If during development, you should set the event types in setup({ types: { events: ... } }).

If during prod, then the wildcard technique will still work by throwing an error. .can(…) does not execute custom actions, but TypeScript should stop you from checking an unknown event.

[dr-skot]

Thanks for the quick reply! I do have the event types set. It's more about detecting runtime failures during development that TypeScript can't catch—when an event doesn't go through because the guard conditions aren't right or the machine's not in the state the client thinks it's in. It can be hard to track those down sometimes because the actor silently ignores them. It would be helpful to get some kind of notification. On the discord server @davidkpiano pointed me to the inspect API, so I'm going to check that out.

…

On Fri, May 17, 2024, at 10:57 AM, David Khourshid wrote: What is your goal? Do you want to prevent unknown events from being sent during development or runtime? If during development, you should set the event types in `setup({ types: { events: ... } })`. If during prod, then the wildcard technique will still work by throwing an error. `.can(…)` does not execute custom actions, but TypeScript should stop you from checking an unknown event. — Reply to this email directly, view it on GitHub <#4124 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN74QCLYXH5SIPJWEOBWO3ZCYLGHAVCNFSM6AAAAAA2ATQYI6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TINZRHE2DS>. You are receiving this because you commented.Message ID: ***@***.***>