-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce TExpressionEvent
generic
#3694
Conversation
🦋 Changeset detectedLatest commit: a758eee The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
👇 Click on the image for a new way to code review
Legend |
packages/core/src/actions.ts
Outdated
TExpressionEvent extends EventObject, | ||
TEvent extends EventObject = TExpressionEvent | ||
>( | ||
event: NoInfer<TEvent>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
previously this was typed as Event<TEvent>
:
xstate/packages/core/src/types.ts
Line 90 in 70f426a
export type Event<TEvent extends EventObject> = TEvent['type'] | TEvent; |
This wasn't correct for events with payload. IIRC we've decided to ditch the idea of extracting "simple" events and allowing them to be used as strings. I think it would be OK-ish to introduce such a "breaking change" (type-level only) in a minor version. Let me know what do you think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's fine. Worst-case scenario, it would only "break" code at the type-level (ignorable) but still work exactly the same.
TContext, | ||
TExpressionEvent extends EventObject, | ||
TEvent extends EventObject = TExpressionEvent | ||
> extends ActionObject<TContext, TExpressionEvent, TEvent> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding this extends
was one of the crucial changes here.
Yeah, this might be too big of a change to introduce to v4. Is there a more limited change that we can make to improve the |
Note that I've tried to ensure maximum (and reasonable) backward compatibility here. That's why I didn't reorder some type parameters and why I put default type arguments in all places that I touched. The only unknown, from my PoV, is how this might impact projects "in the wild". Our types are so complex that it's super hard to predict this. I plan to add a lot of type-related tests in v5 but that's a future talk. The shape of the PR in itself - I think it's good. That doesn't mean that we have to ship this though. I'm really tempted though, just take a look at those DX improvements and correctness! 😅
The question here is - what is our aim with the type-related changes? If I'd know how to change this in a simpler way in v4 then I would do it differently right from the start. The changes in the linked PR are not correct - they just allow things in an unsafe way, so "accidentally" the errors go away. Arguably... the old types weren't that much better (I'd have to take another look to confirm that) so it's not necessarily like those changes introduce a regression (but again, I'd have to recheck that), maybe they just trade one incorrect/unsound thing for another incorrect/unsound thing. |
@Andarist I'll take a deeper look at this. My main goal is to make the normal usage of |
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit a758eee:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, but can we add a // @ts-expect-error
test?
b0bb50d
to
1711278
Compare
c09b713
to
55e2143
Compare
941c4fe
to
c6a9dc7
Compare
context: { | ||
actorRef: undefined | ||
}, | ||
context: {} as Ctx, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why wouldn't actorRef: undefined
work?
27528ad
to
5c313ba
Compare
2c6d655
to
0c335e5
Compare
# Clean up # fixed types # fix more problems manifested in tests # fixed an immer problem
0c335e5
to
072e6bb
Compare
072e6bb
to
f732c0e
Compare
With this change, the inferred types for
raise
are being improved. We can see here that bothTExpressionEvent
andTEvent
are inferred correctly here - to{ type: 'DECIDE'; aloha?: boolean | undefined; }
andGreetingEvent
, respectively.In here we can see that this improves autocomplete capabilities in the IDE because the contextual type is restricted to what can actually be sent to this machine:
And in here we can see that a type error is raised (huehue) correctly when we try to use an invalid event:
I'm not super keen on touching types in v4 as I'd really like to completely rewrite them in v5 (IMHO it's the easiest way to clean them up). OTOH, this brings some very nice improvements to the table.
Our types are so complex that it's quite hard to predict all potential problems with this but, dunno, perhaps it's worth shipping this?
fixes #2897
fixes #1414
fixes #2994