[V5] Will be "strict" mode removed?

[danielkcz]

First a quote from @davidkpiano.

Also, @Andarist said here

Technically it's valid to send any event to a machine - unknown will just get ignored. You should rely on a type system to disallow "invalid" events and not this runtime check.

And here

we might even remove it in v5. It's not set in stone yet, but we've talked about it. I think we should remove it and validate this at all times behind a dev flag, or not validate at all. There is a slight problem with * matcher - using it once within your machine would immediately make your machine non-strict as it would have to accept any event.

---

Alright, let's get it straight here. First of all the * isn't a problem apparently. Check my contrived example...

https://codesandbox.io/s/wizardly-wilbur-b19nj?file=/src/index.js

Furthermore, you can notice that despite sending RETRY event while we are in active state which doesn't use it, there is no error about it which is a good thing. Once we try to send typoed REIRY it correctly fails because it's not mentioned anywhere in the machine.

The case where I would make a typo in the machine itself and have on RETRY along with typoed on REIRY, the strict mode cannot help there. But that can be already handled by TypeScript just fine as you can see in the example (uncomment line 22).

But TypeScript has weak points too when trying to send events across machines. Even with an explicit generic type, it won't catch a problem. It's probably a bug, but currently, it makes strict mode super helpful. (seen on the last line of the example)

Quoting @Andarist again

I think we should remove it and validate this at all times behind a dev flag

I would definitely vote for that approach.

[Andarist]

But TypeScript has weak points too when trying to send events across machines. Even with an explicit generic type, it won't catch a problem.

Could you give an example of that? I feel that I know what you are talking about, but would be great to have this backed up with an example code.

[Andarist]

Why it shouldn't? This line is not associated with the machine itself anyhow, it's just an object (the output of actions.send) describing some action - it actually should accept any event there. You have given it a single TEvent generic which is not about what you can send but what kind of events you accept in your "send expressions" (when specifying, for example, a delay as a function). To limit what type of events you can send you should use a third generic parameter and when you do (actions.send<any, TEvents, TEvents>('REIRY')) then you will observe an error being reported correctly.

[danielkcz]

😆 Are you being serious right now? Do you consider that a good DX when I have to supply 3 generic arguments? Honestly, who would bother to write it like that? It's a lot of extra noise for readability, especially when the name of TEvents needs to be longer because it's imported.

actions.send<any, TImportedChildMachineEvents, TImportedChildMachineEvents>('REIRY', { to: 'child' })

Anyway, that's exactly why I am convinced "strict" mode should stay if we cannot find a good way to type check sending events between machines that work without such a hassle.

I would have been at least expecting it will be able to check against that events union. I have added another example there which shows the principle nicely. I am not sure why it doesn't work with actions.

function invokeCallback(send: Sender<TEvents>) {
  send('REIRY') // how come this is correctly type checked?
}

[Andarist]

Honestly, who would bother to write it like that? It's a lot of extra noise for readability, especially when the name of TEvents needs to be longer because it's imported.

I think you misunderstand those generics a little bit, it's this:

actions.send<any, TCurrentMachineEvents, TImportedChildMachineEvents>('REIRY', { to: 'child' })

As to your invokeCallback example - could you prepare a runnable repro case? This one doesn't look OK and we probably could fix this.

[danielkcz]

It doesn't matter, it's still cluttered and it's unlikely to be adopted massively. Can we please focus this discussion around "strict" mode and not about finding TS crutches that are hard to use? In other words, do you really want to force everyone to use TypeScript with XState? There should be another way for JS people too.

I am not sure what you don't like about invokeCallback, on the contrary, that one is perfectly fine.

[Andarist]

not about finding TS crutches that are hard to use?

IMHO this is important for this discussion because you have also started from a position that TS is not helping you enough in some cases (which I agree on) and this discussion has lead to exposing few potential problems in our current typings that could be improved.

I have just started commenting on this TS stuff because you have presented a few examples for which I had an impression that you thought they shouldn't typecheck, but they are actually correct. So I wanted to clear things up about this.

I am not sure what you don't like about invokeCallback, on the contrary, that one is perfectly fine.

I have meant that this looks like some typing problem and I would love to get a repro case for it, the runtime code looks OK.

Can we please focus this discussion around "strict" mode

I don't think your issue is as much about the strict mode as it is about received events validation, which is not the same (although the latter is included in the strict mode). Could you say that what you want is just being warned about misspelled events?

One potential drawback of making this the default (just warning, nothing more) might be around machines using autoForward 🤔 In those cases, it might create unnecessary warnings (maybe?). Not a super fan of autoForward myself, but we are supporting it so we should have this use case in mind.

[danielkcz]

@Andarist

Why it shouldn't? This line is not associated with the machine itself anyhow, it's just an object (the output of actions.send) describing some action

And about that, the problem is the same when I would want to send an event from within that machine, check line 12 in the linked sandbox. You can't really say that this isn't associated with the machine, right?

entry: actions.send('RELRY')

Once again, I would love to be proved wrong here and have a solid TS type check on all those cases, but that's not happening right now, and as such the "strict" mode is a necessary evil.

[Andarist]

You can't really say that this isn't associated with the machine, right?

Right, this should type check OK. This might be a regression from #1178 . I think we might need to introduce overloads for send as the 3rd generic is only relevant if a custom target (to) is being used. Could you create an issue about it?

[danielkcz]

Issue created: #1250

[danielkcz]

I am not sure what you don't like about invokeCallback, on the contrary, that one is perfectly fine.

I have meant that this looks like some typing problem and I would love to get a repro case for it, the runtime code looks OK.

I still don't follow, type check is perfectly fine there - it warns about typoed event name.

[Andarist]

Ah, sorry - I've misunderstood this part of your post when reading this in a hurry, I have thought that this is not working correctly.

[danielkcz]

Yeah, I was showing it as a nice example where it works nicely :)

[Andarist]

It's a very different context though. The recipient of an event is very clear (and explicitly annotated by you) - that's why it's type-checked OK. A different story that we could check is if using this invokeCallback in a particular machine is sound (from a type system point of view) or if we can use this with an incompatible machine.

[danielkcz]

@Andarist

I don't think your issue is as much about the strict mode as it is about received events validation, which is not the same (although the latter is included in the strict mode). Could you say that what you want is just being warned about misspelled events?

I can agree with that. Given that statecharts are a lot about "magic strings", the validation is important to avoid problems that are harder to spot. One might argue that writing tests is important and do I agree with that too, but in case of a typo, it's even harder to find why the code is not working when a machine is just silently ignoring sent events.

[CodingDive]

Given that statecharts are a lot about "magic strings"

That's why I put all my events and state nodes into an enum or object. Can't ever mistype anything

[danielkcz]

I know, but I dislike enums because of the verbosity, it makes it much harder to read imo. And it's a not a golden bullet either because for every state/event you have to declare enum value and then actually used it inside the type declaration. It's getting too close to Redux boilerplates.

[CodingDive]

I find them verbose too but having a much easier time refactoring and less bugs is more important to me than the readability or additional boilerplate.

I use string enums which makes debugging just a bit easier as I can CONSTANT_CASE all my states and events using the enum key but can keep the camelCase (for states) and UPPER_CASE (for events) convention with the enum value.

enum EVENT { TOGGLE = "TOGGLE" }

enum STATES { ACTIVE = "active", INACTIVE = "inactive" } 

[danielkcz]

I think that strict mode is not that important anymore when utilizing https://github.com/mattpocock/xstate-codegen. It's not a perfect solution yet, but I think it's the correct path instead of relying on runtime errors.