-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Feature/react 18 #3064
Merged
Merged
Feature/react 18 #3064
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
update react dependencies and add use-sync-external-store polyfill
use a version of uSES that actually has an implementation other than "Not Yet Implemented"
looks like we also need the experimental version of react, because v18-alpha doesn't support uSES yet.
update testing-library to v13 alpha
do not update currentResult when it is equal to the previousResult, because we use the currentResult as snapshot for uSES, so it must be as stable as possible
switch forceUpdate with uSES. - I'm not sure if the `updateResult` effect is still necessary, or if it's guaranteed that we can't miss any updates because we don't subscribe in an effect anymore; tests behave the same with / without it - tbd - subscribe must be stable, or else we wind up in an infinite loop. in order to be able to pass `observer.subscribe`, we must bind the function in the constructor
make the first test a bit more stable - we don't want more than 2 results
fix type issues in devtools tests, so we adhere to the new typings of testing-library v13
make devtools test more resilient: act throws an error in the latest version if used liked that, but we don't need it. We can just click the button and use waitFor, as documented here: https://testing-library.com/docs/guide-disappearance#2-using-waitfor
don't re-assign result
bring back the optimistic result; this is debatable because it means we actually _ignore_ whe result returned by uSES, but it makes for fewer re-renders as we can go back to silently update from the effect
useIsFetching to uSES I don't fully understand the test that needed adaption, but the new numbers actually look more correct. The first thing that happens is showing the SecondQuery (after 50ms), and at that time, the FirstQuery is already fetching, so why should there be two zeros in the result array ... judging from the console mock assertion, we are testing if state hasn't been updated on an unmounted component, which now can't happen anymore with uSES, so we can remove it
useIsMutatating to uSES As a positive side-effect, there seem to be fewer re-renders now - the new numbers in the tests do make sense
useMutation to uSES one big change is moving `setOptions` into a useEffect - similar to what `useQuery` is doing. However, we have no `getOptimisticResult` in useMutation, so we'll have to see how this behaves the tests need some love - it's generally working, but the way the tests are written, we're getting some failure.
wait for heading to to to value `3` before asserting the onSuccess / onSettled calls
rewrite test to getByRole
since we're not returning anything from onError or onSettled in the tests, the mutation updates the data on the screen before the callbacks have finished running, which is why the test needs to waitFor the callbacks to have been called
work around console error from uSES by moving the console mock to the client part and / or increasing the assertion count for now
there seems to be one less rendering, likely because of batching, getting rid of one render that has the same assertions as the previous state, which is nice
update shim
update to v18 alpha, which should had the native uSES impl
bump uSES
count renders correctly by incrementing the count in useEffect
bump everything and import from /shim
make test more resilient by not using fireEvent
use findByText for more resilient tests
test against react 17 and react 18
only run bundlewatch once
give a better name
it's optional and we don't do anything meaningful as of now in it; will need to re-add it once we do react18 hydration
This reverts commit eabcd46.
because the latest alpha dropped support for react17
React 18 has been released today and is not compatible with react-query according to npm:
|
# Conflicts: # src/devtools/utils.ts
🎉 This PR is included in version 4.0.0-beta.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.