-
Notifications
You must be signed in to change notification settings - Fork 472
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
fix(wait-for): Don't queue microtasks after condition is met #1073
fix(wait-for): Don't queue microtasks after condition is met #1073
Conversation
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 2b8da94:
|
Codecov Report
@@ Coverage Diff @@
## main #1073 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 25 25
Lines 952 954 +2
Branches 311 312 +1
=========================================
+ Hits 952 954 +2
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
|
||
await Promise.resolve() | ||
|
||
expect(context).toEqual('initial') |
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.
Was no-act
without the change. We had the following schedule-resolution order:
Without this change:
- start
asyncWrapper
- start
unstable_advanceTimersWrapper
- leave
asyncWrapper
- leave
unstable_advanceTimersWrapper
With this change:
- start
asyncWrapper
- start
unstable_advanceTimersWrapper
- leave
unstable_advanceTimersWrapper
- leave
asyncWrapper
In other words, before asyncWrapper
and unstable_advanceTimersWrapper
were interleaved instead of nested.
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.
I didn't realize unstable_advanceTimersWrapper
was a thing 😅 The test looks a bit complicated, but I understand why so that's fine. This looks good to me 👍
Added in #1022 because we can't indiscriminantly wrap I hope the linked issues/threads etc make it possible to follow why we need all of this. Though it's quite involved. Please hit me over the head after React 18 is stable that I should write up why we needed all the changes. Right now I'm too lazy considering all of this may change.
Yeah the test is way too involved for my liking as well. I'm just glad we have some automatic verification though. I wouldn't be surprised if it turns out that the usage of |
RE: #667 (comment) Bookshelf app tests path with this PR (#1073). Ultimately we should add a test that illustrates what's happening in the bookshelf app. Hopefully we can refactor our implementation to fix all tests but keep the code simpler. |
Sounds good to me 👍 |
🎉 This PR is included in version 8.11.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
What:
Fixes integration with of
@testing-library/react@alpha
in React Spectrum when using React 18.Why:
Otherwise context restoration in
unstable_advanceTimersWrapper
becomes unpredictable leading to fixes liked375ff3
(#2526) that seemingly have nothing to do with the test/implemenation but magically fix tests.The implementation change fixed
-- /~https://github.com/adobe/react-spectrum/blob/8dc33dcdab3bb41518daf023c18939e844e843eb/packages/%40react-aria/dnd/test/dnd.test.js#L2072-L2105
How:
Exit the loop once the callback no longer throws instead of unconditionally queuing another microtask.
This may be an issue with how
@testing-library/react
usesunstable_advanceTimersWrapper
.Alternatively, we could flush microtasks before we check the callback. But this was intentionall though we don't have any test/repro for that at the moment /cc @kentcdodds
Checklist:
docs site
[ ]TypeScript definitions updated