feat(react-dom): Add async act#37554
Conversation
|
👋 Hi there! I’ve run some quick performance metrics against master and your PR. This is still an experiment, so don’t panic if I say something crazy! I’m still learning how to interpret these metrics. Let’s review the numbers, shall we? Comparison details 📊
First off, note that the system varied slightly between these two runs, so you’ll have to take these measurements with a grain of salt. It looks like nothing changed too much. I’m pretty lenient since I’m still an experiment, so take a look anyways and make sure nothing looks out of place. If you have any questions or comments about me, you can ping |
typescript-bot
added
Popular package
|
@eps1lon Thank you for submitting this PR! 🔔 @MartynasZilinskas @theruther4d @Jessidhia - please review this PR in the next few days. Be sure to explicitly select If no reviewer appears after a week, a DefinitelyTyped maintainer will review the PR instead. |
| export function act(callback: () => void | undefined): DebugPromiseLike; | ||
| // the "void | undefined" is here to forbid any sneaky return values | ||
| // tslint:disable-next-line: void-return | ||
| export function act(callback: () => Promise<void | undefined>): Promise<undefined>; |
There was a problem hiding this comment.
I don't think this needs multiple signatures; DebugPromiseLike is promise-like, after all:
export function act(callback: () => Promise<void | undefined> | void | undefined): DebugPromiseLike;should be fine. And I'm not sure if it even needs the whole void | undefined thing now that it doesn't need to catch promises in a special way. Maybe getting rid of the undefineds and just using voids is fine now? I don't really understand how that bit was working before. It could also be changed to simply () => any, but that doesn't get the intended semantics across so well.
There was a problem hiding this comment.
DebugPromiseLike is here to throw type errors because it will trigger react warnings if you await the sync act and more importantly can cause subtle scheduling bugs.
() => any is not valid either because react will warn if you return anything but a thenable from it.
There was a problem hiding this comment.
Ah, in that case I think the first signature should become a regular promise, because the recommendation now is to await even synchronous act (if you give it a synchronous function, it may still wait for asynchronous tasks). So maybe combine them with a Promise<void> return type?
There was a problem hiding this comment.
because the recommendation now is to await even synchronous act
Do you have a link for that? I remember a PR where the author for async act explicitly told me this can cause bugs and I'm fairly certain this still issues warnings from react.
There was a problem hiding this comment.
Hmm, looks like I made it up, which is weird because I distinctly remember seeing that from a maintainer in the original tracker. Maybe it was an early thought which got edited out. Anyway doesn't seem to be the case, so I guess it does have to be 2 separate signatures.
typescript-bot
added
the
Unmerged
|
After 5 days, no one has reviewed the PR 😞. A maintainer will be reviewing the PR in the next few days and will either merge it or request revisions. Thank you for your patience! |
|
I just published |
4 participants
Please fill in this template.
npm test.)npm run lint package-name(ortscif notslint.jsonis present).Select one of these and delete the others:
If changing an existing definition:
react-dom/test-utils[ ] If you are making substantial changes, consider adding atslint.jsoncontaining{ "extends": "dtslint/dt.json" }.