feat(infiniteQuery): add possibility to decide which pages should be refetched #2557
Conversation
|
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/tannerlinsley/react-query/Cp49dNZ8MsyxQH5FBFjy9xBn7Wsu |
|
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 56a3e12:
|
src/core/queryClient.ts
Outdated
| this.queryCache.findAll(filters).map(query => query.fetch()) | ||
| this.queryCache.findAll(filters).map(query => | ||
| query.fetch(undefined, { | ||
| meta: { refetchPage: options?.refetchPage }, |
There was a problem hiding this comment.
I played around with this a bit, but I'm not in love with the public api. Two things:
- if you pass
refetchPageon a normal useQuery (non-infinite-query), it doesn't do anything - if you have a queryKey, but no filters, you'd need to do:
queryClient.invalidateQueries('myKey', undefined, {
refetchPage: (page, allPages) => page === allPages[0]
})
yes, you could do:
queryClient.invalidateQueries({ queryKey: 'myKey' }, {
refetchPage: (page, allPages) => page === allPages[0]
})
instead, but the same drawback applies when you want to invalidate everything:
queryClient.invalidateQueries(undefined, {
refetchPage: (page, allPages) => page === allPages[0]
})
we could alternatively add that refetchPage option to queryFilters, similar to refetchActive and refetchInactive flags we can already provide to invalidateQueries. It's not really a query "filter" per se, because it doesn't narrow down anything, but neither is refetchActive, so maybe that distinction doesn't matter that much?
the only thing that comes to my mind to solve issue 1) would be a separate invalidateInfiniteQueries, but that would also mean we'd need refetchInfiniteQueries and resetInfiniteQueries with all the overloads and I don't think that's worth it.
right now, I would go with adding it to the query filters. What do you think @tannerlinsley ?
There was a problem hiding this comment.
I found a reason to maybe keep the current api: the refetch method returned from useInfiniteQuery already takes RefetchOptions, so it's rather easy to make refetchPage work there as well
There was a problem hiding this comment.
I think I would prefer just adding to the query filters and having it be a noop for non-infinite queries. Thoughts?
There was a problem hiding this comment.
yep, I can do that, let me see how that looks. Would we still want to have it as an option for refetch returned from useQuery ? I would say yes, and we could just add it to the options there as well
There was a problem hiding this comment.
what do you think?
…refetched make refetchPage also be respected on the refetch function returned from useInfiniteQuery
…refetched add possibility for types to flow through so that refetch from useInfiniteQuery will infer types of pages
…refetched test for refetch method returned from useInfiniteQuery
…refetched forgot a type
…refetched add tests for refetchQueries and invalidateQueries for invalidation, we also need to refetch inactiveQueries, because creating a new Observer doesn't add it as active to the client
…refetched test for resetQueries, requires initialData
…refetched refetchPage signature now takes page, index, allPages this is the same signature as e.g. Array.prototype.map
…refetched documentation for refetchPage
…refetched move refetchPage into queryFilters
|
🎉 This PR is included in version 3.20.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
2 participants
refs #1866
missing: