Xstate: Typescript 'matches' issue on xstate/react rc.1 and later.

[timothyallan]

Description
I've got a strange one. Typings for the context of Machines vanish depending on how you do a matches call.

Actual Result

Here I have a pretty typical check to see if I'm in a particular state. However, you can see that the context type is now showing as any, when it's actually defined when I create the machine.

If I wrap that check in a Boolean, the context typings are maintained, and Typescript correctly reports that I've got an error.

Expected Result
Maintain the typings without having to 'wrap' the match function in a Boolean. This only seems to be the case after 1.0.0-rc.1 as well. Releases prior to that seem to work well.

https://codesandbox.io/s/unruffled-bassi-ts45b

Additional context
"xstate": "^4.11.0"
"@xstate/react": "^1.0.0-rc.5"

[davidkpiano]

That is really weird. What version of TypeScript are you using?

[timothyallan]

Uhh, yeah, it's super weird.

I'm using 3.9.6. It does it in that codesandbox link as well if you comment/uncomment my if's, and it looks like it's using Typescript v3.3.3

[CodingDive]

This may be related to #1142, #947, #1184. You can find a few workarounds that may work for you there

[Andarist]

This actually looks slightly different to me. In all linked issues this conditional type:
https://github.com/davidkpiano/xstate/blob/597cfdc659b03f2095e73faf3f82702ae68a3911/packages/core/src/State.ts#L294
was resolved to never, but in here it seems that the other branch is chosen and because supplied default here:
https://github.com/davidkpiano/xstate/blob/597cfdc659b03f2095e73faf3f82702ae68a3911/packages/xstate-react/src/useMachine.ts#L105
is different than what we default to in the core:
https://github.com/davidkpiano/xstate/blob/597cfdc659b03f2095e73faf3f82702ae68a3911/packages/core/src/State.ts#L87
this is not working properly.

I thought that simply providing the same default would solve this:
https://codesandbox.io/s/mutable-water-gjqm4?file=/src/index.tsx
but, unfortunately, it doesn't - for some reason. However, if I supply manually that default in a place of TTypestate to State then the correct problem gets reported.

EDIT:// Ok, I've figured it out - by not supplying any type parameters to that useMachine call the type inference kicked in and it has ignored my default for TTypestate and it got just inferred to any because of other types used in this expression.

I think we should just use the same default for TTypestate consistently across the codebase and it should fix this problem. Gonna prepare a PR for this soon.