feat(react-query): add support for infinite queries in QueriesHydration #1874
Conversation
- Enhanced QueriesHydration to accept infiniteQueryOptions alongside regular query options. - Added tests to verify hydration and SSR behavior for infinite queries, including error handling and state dehydration. - Updated type definitions to reflect the new query structure. Co-authored-by: Yoomin Kang <[email protected]>
🦋 Changeset detectedLatest commit: f47cc33 The changes in this PR will be included in the next version bump. This PR includes changesets to release 7 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
People can be co-author:
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Size Change: +112 B (+0.13%) Total Size: 88.7 kB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
Pull request overview
This pull request adds support for infinite queries to the QueriesHydration component in both @suspensive/react-query-4 and @suspensive/react-query-5 packages. The implementation allows users to pass infiniteQueryOptions alongside regular queryOptions when pre-fetching queries for server-side rendering.
Changes:
- Updated
QueriesHydrationto accept bothQueryOptionsandUseInfiniteQueryOptionsin the queries array - Modified the fetching logic to use
fetchInfiniteQueryfor infinite queries andfetchQueryfor regular queries - Added comprehensive type tests and runtime tests for infinite query support
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| packages/react-query-5/src/QueriesHydration.tsx | Added UseInfiniteQueryOptions type support and runtime detection logic to handle infinite queries |
| packages/react-query-5/src/QueriesHydration.test-d.tsx | Added type tests for infinite query options and mixed query arrays |
| packages/react-query-5/src/QueriesHydration.spec.tsx | Added runtime tests for infinite query fetching, hydration, error handling, and dehydration |
| packages/react-query-4/src/QueriesHydration.tsx | Added UseInfiniteQueryOptions type support and runtime detection logic (v4 API compatible) |
| packages/react-query-4/src/QueriesHydration.test-d.tsx | Added type tests for infinite query options (without initialPageParam per v4 API) |
| packages/react-query-4/src/QueriesHydration.spec.tsx | Added runtime tests accounting for v4 API differences (no initialPageParam) |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| /** | ||
| * An array of query options to be fetched on the server. Each query must include a `queryKey`. | ||
| */ | ||
| queries: WithRequired<QueryOptions<any, any, any, any>, 'queryKey'>[] | ||
| queries: ( | ||
| | WithRequired<QueryOptions<any, any, any, any>, 'queryKey'> | ||
| | WithRequired<UseInfiniteQueryOptions<any, any, any, any, any>, 'queryKey'> | ||
| )[] |
There was a problem hiding this comment.
The JSDoc comment for the queries parameter should be updated to mention that it now accepts both regular query options and infinite query options. Consider updating it to something like: "An array of query options or infinite query options to be fetched on the server. Each query must include a queryKey."
| /** | ||
| * An array of query options to be fetched on the server. Each query must include a `queryKey`. | ||
| */ | ||
| queries: WithRequired<QueryOptions<any, any, any, any>, 'queryKey'>[] | ||
| queries: ( | ||
| | WithRequired<QueryOptions<any, any, any, any>, 'queryKey'> | ||
| | WithRequired<UseInfiniteQueryOptions<any, any, any, any, any>, 'queryKey'> | ||
| )[] |
There was a problem hiding this comment.
The JSDoc comment for the queries parameter should be updated to mention that it now accepts both regular query options and infinite query options. Consider updating it to something like: "An array of query options or infinite query options to be fetched on the server. Each query must include a queryKey."
| await Promise.all(queries.map((query) => queryClient.ensureQueryData(query))) | ||
| await Promise.all( | ||
| queries.map((query) => | ||
| 'getNextPageParam' in query ? queryClient.fetchInfiniteQuery(query) : queryClient.fetchQuery(query) |
There was a problem hiding this comment.
The change from ensureQueryData to fetchQuery for regular queries changes the caching behavior. ensureQueryData would return cached data if available, while fetchQuery always fetches fresh data. This could be a breaking change if users pass a custom queryClient with pre-existing cached data. Consider using ensureQueryData for regular queries to maintain backward compatibility, or document this behavioral change if it's intentional.
| 'getNextPageParam' in query ? queryClient.fetchInfiniteQuery(query) : queryClient.fetchQuery(query) | |
| 'getNextPageParam' in query ? queryClient.fetchInfiniteQuery(query) : queryClient.ensureQueryData(query) |
| await Promise.all(queries.map((query) => queryClient.ensureQueryData(query))) | ||
| await Promise.all( | ||
| queries.map((query) => | ||
| 'getNextPageParam' in query ? queryClient.fetchInfiniteQuery(query) : queryClient.fetchQuery(query) |
There was a problem hiding this comment.
The change from ensureQueryData to fetchQuery for regular queries changes the caching behavior. ensureQueryData would return cached data if available, while fetchQuery always fetches fresh data. This could be a breaking change if users pass a custom queryClient with pre-existing cached data. Consider using ensureQueryData for regular queries to maintain backward compatibility, or document this behavioral change if it's intentional.
| 'getNextPageParam' in query ? queryClient.fetchInfiniteQuery(query) : queryClient.fetchQuery(query) | |
| 'getNextPageParam' in query ? queryClient.fetchInfiniteQuery(query) : queryClient.ensureQueryData(query) |
There was a problem hiding this comment.
@manudeli It looks like the logic changed from queryClient.ensureQueryData to queryClient.fetchQuery. Was this intentional?
There was a problem hiding this comment.
At first, why I consider changing fetchQuery and fetchInfiniteQuery instead of ensureQueryData and ensureInfiniteQueryData is that TanStack Query v4 have no ensureInfiniteQueryData.
but when I see implementation of fetchQuery and fetchInfiniteQuery, I thought it could be enough because they already check if query is stale
There was a problem hiding this comment.
Is there a specific reason for distinguishing Infinite using the getNextPageParam field? Was it chosen because it's a field present in both Query v4 and v5?
(I'm just asking out of curiosity)
There was a problem hiding this comment.
Was it chosen because it's a field present in both Query v4 and v5?
That is right
There was a problem hiding this comment.
At first, why I consider changing
fetchQueryandfetchInfiniteQueryinstead ofensureQueryDataandensureInfiniteQueryDatais that TanStack Query v4 have noensureInfiniteQueryData.but when I see implementation of
fetchQueryandfetchInfiniteQuery, I thought it could be enough because they already check if query is stale
I understand the context you’re describing.
From an SSR and hydration perspective, this makes the fetch timing and outcome more explicit compared to relying on the background fetch semantics of ensure*.
There was a problem hiding this comment.
Is there a specific reason for distinguishing Infinite using the
getNextPageParamfield? Was it chosen because it's a field present in both Query v4 and v5?(I'm just asking out of curiosity)
I also wondered whether that condition was reliable enough to clearly distinguish between queryOptions and infiniteQueryOptions. Because of that, I considered splitting them into QueryHydration and InfiniteQueryHydration, but I feel that approach might result in a poorer developer experience.
There was a problem hiding this comment.
Is there a specific reason for distinguishing Infinite using the
getNextPageParamfield? Was it chosen because it's a field present in both Query v4 and v5?
(I'm just asking out of curiosity)I also wondered whether that condition was reliable enough to clearly distinguish between
queryOptionsandinfiniteQueryOptions. Because of that, I considered splitting them intoQueryHydrationandInfiniteQueryHydration, but I feel that approach might result in a poorer developer experience.
That's right, that's why I asked, but when looking at the codebase of Query (considering both v4 and v5),
ref: https://github.com/TanStack/query/blob/main/packages/query-core/src/types.ts#L284
- getNextPageParam
- getPreviousPageParam
- initialPageParam
We have to choose one of these three. There is no internal field that distinguishes the query type.
There was a problem hiding this comment.
initialPageParam is not required field for infiniteQuery of TanStack Query v4. so I drop it as choice
getPreviousPageParam is not required field at TanStack Query v4, v5 both
getNextPageParam is the only required field to do this.
I also wondered whether that condition was reliable enough to clearly distinguish between queryOptions and infiniteQueryOptions. Because of that, I considered splitting them into QueryHydration and InfiniteQueryHydration, but I feel that approach might result in a poorer developer experience.
Because QueriesHydration wrap Hydrate & HydrationBoundary can accept dehydrated QueryClient can work with queryOptions & infiniteQueryOptions, I think that QueriesHydration handle queryOptions & infiniteQueryOptions both is better than making InfiniteQueriesHydration
|
Will the document be updated in the next PR? |
I need to do it now, Thanks! |
…nfinite queries - Added examples demonstrating the use of `infiniteQueryOptions` alongside regular queries. - Updated the props description to clarify that both regular and infinite queries can be mixed in the same array. - Translated the new content into Korean for localization. This update improves clarity for users implementing infinite queries with QueriesHydration.
Co-authored-by: gwansikk <[email protected]> Co-authored-by: kangju2000 <[email protected]>
|
@gwansikk @kangju2000 Thanks for your reviewing! I added docs now too |
…Options for server-side data prefetching - Added a note on using `queryOptions` with `QueriesHydration` for server-side data prefetching. - Suggested wrapping components with their own `Suspense` and `QueriesHydration` for improved HTML Streaming. - Updated the Korean translation to reflect these changes. This enhances the clarity and usability of the QueriesHydration documentation.
manudeli
deleted the
react-query/feat/QueriesHydration-use-infiniteQueryOptions
branch
This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated. # Releases ## @suspensive/[email protected] ### Minor Changes - [#1874](#1874) [`8260f86`](8260f86) Thanks [@manudeli](https://github.com/manudeli)! - feat(react-query): add support for infinite queries in QueriesHydration ## @suspensive/[email protected] ### Minor Changes - [#1874](#1874) [`8260f86`](8260f86) Thanks [@manudeli](https://github.com/manudeli)! - feat(react-query): add support for infinite queries in QueriesHydration ## @suspensive/[email protected] ### Patch Changes - Updated dependencies \[[`8260f86`](8260f86)]: - @suspensive/[email protected] - @suspensive/[email protected] ## @suspensive/[email protected] ## @suspensive/[email protected] ## @suspensive/[email protected] ## @suspensive/[email protected]
Suggested by @gs18004
support infiniteQueryOptions for QueriesHydration
PR Checklist