-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
feat: add support for React.use()
#7988
base: main
Are you sure you want to change the base?
Conversation
☁️ Nx Cloud ReportCI is running/has finished running commands for commit 954d85b. As they complete they will appear below. Click to see the status, the terminal output, and the build insights. 📂 See all runs for this CI Pipeline Execution ✅ Successfully ran 2 targetsSent with 💌 from NxCloud. |
More templates
@tanstack/angular-query-devtools-experimental
@tanstack/eslint-plugin-query
@tanstack/angular-query-experimental
@tanstack/query-async-storage-persister
@tanstack/query-broadcast-client-experimental
@tanstack/query-core
@tanstack/query-persist-client-core
@tanstack/query-devtools
@tanstack/query-sync-storage-persister
@tanstack/react-query
@tanstack/react-query-next-experimental
@tanstack/react-query-devtools
@tanstack/react-query-persist-client
@tanstack/solid-query
@tanstack/solid-query-devtools
@tanstack/solid-query-persist-client
@tanstack/svelte-query
@tanstack/svelte-query-devtools
@tanstack/svelte-query-persist-client
@tanstack/vue-query
@tanstack/vue-query-devtools
commit: |
This comment was marked as outdated.
This comment was marked as outdated.
ec583d5
to
8cbd6a0
Compare
This comment was marked as outdated.
This comment was marked as outdated.
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.
Fantastic! 👏👏 This is pretty complex, so I'll need to some more time to really wrap my head around things.
So many great tests here! Do you think it would make sense to also add some tests with <HydrationBoundary>
, both when we de/rehydrate already awaited data, and when we de/rehydrate a promise?
client.getQueryCache().get(defaultedOptions.queryHash)?.promise | ||
|
||
promise?.catch(noop).finally(() => { | ||
if (!observer.hasListeners()) { |
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'm trying to wrap my head around this all. Why are we checking for !observer.hasListeners()
here?
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.
Just to prevent updateResult()
to be called twice - if it has listeners, updateResult
will be called
(It will work without this check too 🤷♂️)
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 I just checked, if we remove both checks for !observer.hasListeners()
, all the tests still pass. if we want to keep these checks, we should add tests where this fails @KATT. I know that calling updateResult
multiple times might e.g. re-run inline select
functions, but I'm not sure if that's worth optimizing for ...
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 tried adding a test for it by
vi.spyOn(QueryObserver.prototype, 'updateResult')
but it's called a bunch of times within a render so adding a test [that won't break randomly when changing other things] the way I thought it will be quite hard
feel free to delete the optimization
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've deleted the first check, because it's technically impossible that willFetch
is true and we have an observer. I've kept the second check because maybe an observer shows up in between: a9148ba
I think I need to marinate this a bit. I mean, on one hand it should be "safe" to do. On the other, is it always desirable? I'm thinking about (future) cases like pre-rendering, the If there are any issues there, I fully expect |
yes, this auto_prefetching was pretty much taken from the |
Ping me know if you need anything on my end here or have questions that I can help answer, I don't see much tangible feedback as of yet ☺ |
This user-land implementation got me thinking: why don't we also do the promise handling in the react layer rather than the observer 🤔. It looks way simplified. What am I missing 😂? |
@KATT I added more tests, and one scenario is failing (this one): if we cancel the query while we are suspending, we stay in a forever pending state. I think the problem is that we just revert to the previous state if we get a query cancelation, and state happens to be query/packages/query-core/src/query.ts Lines 587 to 589 in 55b6c19
I'm not even sure rejecting the promise the right expectation here, as the query isn't in error state. Honestly not sure what should happen here - maybe staying in |
Good catch. Not sure what the right approach here is. I've never cancelled a query and don't see why I would ever do that 😅, but I understand people will use it and break it. Hm. I thiiiiiink rejecting it with an |
Closes #7980
Progress
useQuery()
useInfiniteQuery()