init query rename and delegation #9835
Conversation
🦋 Changeset detectedLatest commit: 1338e8e The changes in this PR will be included in the next version bump. This PR includes changesets to release 19 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 |
WalkthroughAdds imperative methods Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant Caller as Caller
participant QClient as QueryClient
participant CoreExec as Core Executor
participant Cache as Cache/Network
participant Select as select (optional)
Caller->>QClient: query(options) / infiniteQuery(options)
QClient->>CoreExec: delegate with QueryExecuteOptions / InfiniteQueryExecuteOptions
CoreExec->>Cache: fetch/resolve raw TQueryData or pages
Cache-->>CoreExec: raw TQueryData or pages
alt select provided
CoreExec->>Select: apply select(raw TQueryData or pages)
Select-->>CoreExec: transformed TData / pages
CoreExec-->>QClient: Promise<TData / InfiniteData<TData,...>>
else no select
CoreExec-->>QClient: Promise<TQueryData / InfiniteData<TQueryData,...>>
end
QClient-->>Caller: resolved data
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes
Suggested reviewers
Poem
Pre-merge checks and finishing touches✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
| Command | Status | Duration | Result |
|---|---|---|---|
nx affected --targets=test:sherif,test:knip,tes... |
❌ Failed | 1m 15s | View ↗ |
nx run-many --target=build --exclude=examples/*... |
❌ Failed | 5s | View ↗ |
☁️ Nx Cloud last updated this comment at 2025-11-05 14:08:59 UTC
sorry the idea was not to rename those, but to add new methods and deprecate the old ones. Otherwise, this would be a breaking change. |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #9835 +/- ##
===========================================
+ Coverage 45.75% 59.74% +13.99%
===========================================
Files 200 129 -71
Lines 8408 5627 -2781
Branches 1929 1536 -393
===========================================
- Hits 3847 3362 -485
+ Misses 4113 1960 -2153
+ Partials 448 305 -143 🚀 New features to boost your workflow:
|
DogPawHat
force-pushed
the
implement-simplified-imperitive-methods
branch
from
b3a20d4 to
46d274c
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
.changeset/wise-suns-ask.md(1 hunks)packages/query-core/src/__tests__/queryClient.test-d.tsx(2 hunks)packages/query-core/src/__tests__/queryClient.test.tsx(9 hunks)packages/query-core/src/queryClient.ts(6 hunks)packages/vue-query/src/queryClient.ts(1 hunks)
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-08-19T03:18:18.303Z
Learnt from: oscartbeaumont
Repo: TanStack/query PR: 9564
File: packages/solid-query-devtools/src/production.tsx:2-3
Timestamp: 2025-08-19T03:18:18.303Z
Learning: In the solid-query-devtools package, the codebase uses a pattern of type-only default imports combined with typeof for component type annotations (e.g., `import type SolidQueryDevtoolsComp from './devtools'` followed by `typeof SolidQueryDevtoolsComp`). This pattern is consistently used across index.tsx and production.tsx files, and the maintainers prefer consistency over changing this approach.
Applied to files:
packages/query-core/src/__tests__/queryClient.test-d.tsx
📚 Learning: 2025-09-02T17:57:33.184Z
Learnt from: TkDodo
Repo: TanStack/query PR: 9612
File: packages/query-async-storage-persister/src/asyncThrottle.ts:0-0
Timestamp: 2025-09-02T17:57:33.184Z
Learning: When importing from tanstack/query-core in other TanStack Query packages like query-async-storage-persister, a workspace dependency "tanstack/query-core": "workspace:*" needs to be added to the package.json.
Applied to files:
.changeset/wise-suns-ask.md
🧬 Code graph analysis (4)
packages/query-core/src/__tests__/queryClient.test-d.tsx (3)
packages/query-core/src/types.ts (1)
InfiniteData(204-207)packages/query-core/src/queryClient.ts (1)
infiniteQuery(395-417)packages/vue-query/src/queryClient.ts (1)
infiniteQuery(328-346)
packages/query-core/src/__tests__/queryClient.test.tsx (2)
packages/query-core/src/utils.ts (2)
noop(82-82)sleep(363-367)packages/query-core/src/types.ts (1)
QueryFunction(96-100)
packages/vue-query/src/queryClient.ts (3)
packages/query-core/src/types.ts (5)
DefaultError(47-51)QueryKey(53-61)FetchQueryOptions(491-507)FetchInfiniteQueryOptions(548-565)InfiniteData(204-207)packages/vue-query/src/types.ts (1)
MaybeRefDeep(29-37)packages/vue-query/src/utils.ts (1)
cloneDeepUnref(70-97)
packages/query-core/src/queryClient.ts (2)
packages/query-core/src/utils.ts (1)
noop(82-82)packages/query-core/src/types.ts (5)
DefaultError(47-51)QueryKey(53-61)FetchQueryOptions(491-507)FetchInfiniteQueryOptions(548-565)InfiniteData(204-207)
🪛 LanguageTool
.changeset/wise-suns-ask.md
[grammar] ~6-~6: Ensure spelling is correct
Context: ...tanstack/vue-query': minor --- renamed imperitive methods
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🔇 Additional comments (8)
packages/query-core/src/queryClient.ts (5)
140-159: LGTM! ensureQueryData correctly delegates to the new query method.The internal delegation to
querywithstaleTime: 'static'maintains the expected behavior while utilizing the new method.
336-365: Verify alignment with maintainer expectations regarding API migration strategy.Per TkDodo's comment, the original intent was to "add new methods and deprecate the old ones to avoid a breaking change, not to remove/rename them outright." While this implementation maintains backward compatibility by keeping
fetchQueryas a wrapper, please confirm that makingquerythe primary implementation (rather than keepingfetchQueryas primary and addingqueryas an alias) aligns with the team's migration strategy.
384-393: LGTM! prefetchQuery correctly delegates to the new query method.The delegation pattern with
.then(noop).catch(noop)properly maintains the fire-and-forget prefetch behavior.
395-417: LGTM! infiniteQuery implementation is clean and consistent.The method correctly sets the
infiniteQueryBehaviorand delegates to thequerymethod. The type assertion on line 416 is necessary due to the behavior transformation.
436-452: LGTM! prefetchInfiniteQuery correctly delegates to the new infiniteQuery method.The delegation pattern maintains the fire-and-forget prefetch behavior.
packages/query-core/src/__tests__/queryClient.test-d.tsx (1)
313-328: LGTM! Type assertions for new methods are comprehensive and correct.The type checks for
queryandinfiniteQuerymethods properly cover both fully typed and untyped scenarios, maintaining consistency with the existing test structure.Also applies to: 462-477
packages/query-core/src/__tests__/queryClient.test.tsx (1)
11-11: LGTM! Comprehensive test coverage for the new query methods.The test additions are excellent:
- Properly imports
nooputility for prefetch patterns- Marks old test suites with
@deprecatedcomments for clarity- Provides thorough coverage of new
queryandinfiniteQuerymethods including:
- Static staleTime behavior
- Prefetching scenarios
- Type safety validation
- Edge cases (cache hits, invalidation, GC, etc.)
- Maintains parallel structure with legacy tests while validating new functionality
Also applies to: 453-453, 529-620, 622-622, 683-720, 753-753, 928-1100, 1102-1102, 1147-1189, 1191-1191, 1281-1374, 1376-1376, 1426-1477
packages/vue-query/src/queryClient.ts (1)
256-346: LGTM! Vue Query extensions for new methods are well-implemented.The
queryandinfiniteQuerymethods properly:
- Provide overloads for both plain and
MaybeRefDeepoptions- Use
cloneDeepUnrefto handle Vue's reactive refs correctly- Delegate to the parent QueryClient implementation
- Follow the established pattern used by other methods in this class
|
From #9135:
|
DogPawHat
force-pushed
the
implement-simplified-imperitive-methods
branch
from
c18dfc0 to
7670b40
Compare
…DogPawHat/query into implement-simplified-imperitive-methods
| initialPageParam: 1, | ||
| }) | ||
|
|
||
| const data = await new QueryClient().infiniteQuery(options) |
There was a problem hiding this comment.
Known type failures here.
as far as I know a select pass into a useInfiniteQuery can transform the data: InfiniteData into whatever (e.g. an Array<>) and that will end up being the data returned from the infinite query*. infiniteQuery should do the same I think, but we've got a big type mismatch here at the moment.
*I suspect this is not the best idea
There was a problem hiding this comment.
Type errors from my local VSCode:
Types of property 'select' are incompatible.
Type '((data: InfiniteData<string, number>) => string[]) | undefined' is not assignable to type '((data: InfiniteData<string, number>) => string) | undefined'.
Type '(data: InfiniteData<string, number>) => string[]' is not assignable to type '(data: InfiniteData<string, number>) => string'.
Type 'string[]' is not assignable to type 'string'.ts(2345)
There was a problem hiding this comment.
since it works for useInfiniteQuery, it should also work for client.infiniteQuery()
There was a problem hiding this comment.
Actionable comments posted: 4
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
.changeset/famous-owls-battle.md(1 hunks)packages/query-core/src/__tests__/queryClient.test-d.tsx(7 hunks)packages/query-core/src/__tests__/queryClient.test.tsx(9 hunks)packages/query-core/src/queryClient.ts(8 hunks)packages/query-core/src/types.ts(3 hunks)packages/react-query/src/__tests__/infiniteQueryOptions.test-d.tsx(3 hunks)packages/react-query/src/__tests__/queryOptions.test-d.tsx(2 hunks)packages/vue-query/src/queryClient.ts(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- packages/react-query/src/tests/queryOptions.test-d.tsx
- packages/react-query/src/tests/infiniteQueryOptions.test-d.tsx
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-08-19T03:18:18.303Z
Learnt from: oscartbeaumont
Repo: TanStack/query PR: 9564
File: packages/solid-query-devtools/src/production.tsx:2-3
Timestamp: 2025-08-19T03:18:18.303Z
Learning: In the solid-query-devtools package, the codebase uses a pattern of type-only default imports combined with typeof for component type annotations (e.g., `import type SolidQueryDevtoolsComp from './devtools'` followed by `typeof SolidQueryDevtoolsComp`). This pattern is consistently used across index.tsx and production.tsx files, and the maintainers prefer consistency over changing this approach.
Applied to files:
packages/query-core/src/__tests__/queryClient.test-d.tsx
📚 Learning: 2025-09-02T17:57:33.184Z
Learnt from: TkDodo
Repo: TanStack/query PR: 9612
File: packages/query-async-storage-persister/src/asyncThrottle.ts:0-0
Timestamp: 2025-09-02T17:57:33.184Z
Learning: When importing from tanstack/query-core in other TanStack Query packages like query-async-storage-persister, a workspace dependency "tanstack/query-core": "workspace:*" needs to be added to the package.json.
Applied to files:
.changeset/famous-owls-battle.md
🧬 Code graph analysis (4)
packages/query-core/src/__tests__/queryClient.test-d.tsx (2)
packages/query-core/src/queryClient.ts (1)
infiniteQuery(409-431)packages/query-core/src/types.ts (2)
InfiniteData(204-207)InfiniteQueryExecuteOptions(568-586)
packages/query-core/src/queryClient.ts (4)
packages/query-core/src/utils.ts (2)
noop(82-82)resolveStaleTime(101-113)packages/query-core/src/types.ts (7)
DefaultError(47-51)QueryKey(53-61)QueryExecuteOptions(491-509)FetchQueryOptions(511-527)InfiniteQueryExecuteOptions(568-586)FetchInfiniteQueryOptions(588-605)InfiniteData(204-207)packages/query-core/src/query.ts (1)
isStale(296-306)packages/vue-query/src/queryClient.ts (1)
query(294-314)
packages/query-core/src/__tests__/queryClient.test.tsx (2)
packages/query-core/src/utils.ts (2)
noop(82-82)sleep(363-367)packages/query-core/src/types.ts (1)
QueryFunction(96-100)
packages/vue-query/src/queryClient.ts (3)
packages/query-core/src/types.ts (5)
DefaultError(47-51)QueryKey(53-61)QueryExecuteOptions(491-509)InfiniteQueryExecuteOptions(568-586)InfiniteData(204-207)packages/vue-query/src/types.ts (1)
MaybeRefDeep(29-37)packages/vue-query/src/utils.ts (1)
cloneDeepUnref(70-97)
🪛 Biome (2.1.2)
packages/query-core/src/__tests__/queryClient.test-d.tsx
[error] 342-342: Const declarations must have an initialized value.
This variable needs to be initialized.
(parse)
[error] 342-342: Shouldn't redeclare 'infiniteQueryOptions'. Consider to delete it or rename it.
'infiniteQueryOptions' is defined here:
(lint/suspicious/noRedeclare)
[error] 441-441: This variable is used before its declaration.
The variable is declared here:
(lint/correctness/noInvalidUseBeforeDeclaration)
[error] 443-443: Shouldn't redeclare 'infiniteQuery'. Consider to delete it or rename it.
'infiniteQuery' is defined here:
(lint/suspicious/noRedeclare)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Test
🔇 Additional comments (7)
packages/query-core/src/__tests__/queryClient.test-d.tsx (7)
161-172: LGTM!The test correctly verifies that
fetchQuerydoes not accept theselectoption, maintaining backward compatibility as intended in the PR design.
174-227: LGTM!The tests correctly verify:
selectoption is not allowed onfetchInfiniteQuery(backward compatibility)pagesparameter is properly typedgetNextPageParamis required whenpagesis specified
229-239: LGTM!The test correctly verifies that the new
querymethod accepts theselectoption, which is the key differentiator from thefetchQuerycompatibility wrapper.
242-257: Verify whetherselectshould be allowed oninfiniteQuery.This test asserts that
selectis not allowed oninfiniteQuery, but:
- Lines 336-339 show
InfiniteQueryExecuteOptionsbeing used with aselectoption successfully- Unlike the
fetchInfiniteQuerytest (line 183), there's no@ts-expect-errorannotation on theselectproperty (line 249)Based on the implementation where
infiniteQuerydelegates toquery(which supports select), it appearsselectshould be allowed. Please clarify the intended behavior and add the@ts-expect-errorannotation if select is truly not supported, or update the test description if it is supported.
428-429: LGTM!The type check correctly verifies that
queryreturns the expectedTDatatype.
578-579: LGTM!The type check correctly verifies that
queryreturnsunknownwhen called with untyped options.
583-593: LGTM!The type checks correctly verify the return types for
fetchInfiniteQueryandinfiniteQuerywith untyped options, both returningInfiniteData<unknown, unknown>.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.changeset/famous-owls-battle.md(1 hunks)packages/query-core/src/__tests__/queryClient.test-d.tsx(7 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- .changeset/famous-owls-battle.md
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-08-19T03:18:18.303Z
Learnt from: oscartbeaumont
Repo: TanStack/query PR: 9564
File: packages/solid-query-devtools/src/production.tsx:2-3
Timestamp: 2025-08-19T03:18:18.303Z
Learning: In the solid-query-devtools package, the codebase uses a pattern of type-only default imports combined with typeof for component type annotations (e.g., `import type SolidQueryDevtoolsComp from './devtools'` followed by `typeof SolidQueryDevtoolsComp`). This pattern is consistently used across index.tsx and production.tsx files, and the maintainers prefer consistency over changing this approach.
Applied to files:
packages/query-core/src/__tests__/queryClient.test-d.tsx
🧬 Code graph analysis (1)
packages/query-core/src/__tests__/queryClient.test-d.tsx (3)
packages/query-core/src/queryClient.ts (2)
QueryClient(63-692)infiniteQuery(409-431)packages/vue-query/src/queryClient.ts (2)
QueryClient(39-589)infiniteQuery(348-366)packages/query-core/src/types.ts (2)
InfiniteData(204-207)InfiniteQueryExecuteOptions(568-586)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Preview
- GitHub Check: Test
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
packages/query-core/src/__tests__/queryClient.test-d.tsx(7 hunks)
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: DogPawHat
Repo: TanStack/query PR: 9835
File: packages/query-core/src/__tests__/queryClient.test-d.tsx:242-256
Timestamp: 2025-11-02T22:52:33.049Z
Learning: In the TanStack Query codebase, the new `query` and `infiniteQuery` methods support the `select` option for data transformation, while the legacy `fetchQuery` and `fetchInfiniteQuery` methods do not support `select` and should reject it at the type level.
📚 Learning: 2025-11-02T22:52:33.049Z
Learnt from: DogPawHat
Repo: TanStack/query PR: 9835
File: packages/query-core/src/__tests__/queryClient.test-d.tsx:242-256
Timestamp: 2025-11-02T22:52:33.049Z
Learning: In the TanStack Query codebase, the new `query` and `infiniteQuery` methods support the `select` option for data transformation, while the legacy `fetchQuery` and `fetchInfiniteQuery` methods do not support `select` and should reject it at the type level.
Applied to files:
packages/query-core/src/__tests__/queryClient.test-d.tsx
📚 Learning: 2025-08-19T03:18:18.303Z
Learnt from: oscartbeaumont
Repo: TanStack/query PR: 9564
File: packages/solid-query-devtools/src/production.tsx:2-3
Timestamp: 2025-08-19T03:18:18.303Z
Learning: In the solid-query-devtools package, the codebase uses a pattern of type-only default imports combined with typeof for component type annotations (e.g., `import type SolidQueryDevtoolsComp from './devtools'` followed by `typeof SolidQueryDevtoolsComp`). This pattern is consistently used across index.tsx and production.tsx files, and the maintainers prefer consistency over changing this approach.
Applied to files:
packages/query-core/src/__tests__/queryClient.test-d.tsx
🧬 Code graph analysis (1)
packages/query-core/src/__tests__/queryClient.test-d.tsx (2)
packages/query-core/src/queryClient.ts (1)
infiniteQuery(409-431)packages/query-core/src/types.ts (2)
InfiniteData(204-207)InfiniteQueryExecuteOptions(568-586)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Test
- GitHub Check: Preview
🔇 Additional comments (5)
packages/query-core/src/__tests__/queryClient.test-d.tsx (5)
13-13: LGTM!The addition of
InfiniteQueryExecuteOptionsto the imports aligns with the new public API surface introduced in this PR.
161-172: LGTM!This test correctly validates that the legacy
fetchQuerymethod does not support theselectoption, with proper use of@ts-expect-errorto enforce the type constraint.
174-227: LGTM!The tests for
fetchInfiniteQuerycorrectly validate the legacy behavior, including:
- Properly rejecting
selectoption with@ts-expect-error- Validating the
pagesoption with correct type expectations- Enforcing required parameter constraints
229-239: LGTM!This test correctly validates that the new
querymethod supports theselectoption for data transformation, properly demonstrating the enhanced functionality compared to the legacyfetchQuery.
328-336: LGTM!The integration of the new
queryandinfiniteQuerymethods into the fully-typed and untyped test sections is correct:
- Proper usage of
InfiniteQueryExecuteOptions<TData, TError>type- Correct type expectations for return values
- Good coverage of both typed and untyped variants
Also applies to: 422-423, 434-435, 569-570, 581-584
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/query-core/src/__tests__/queryClient.test-d.tsx (1)
205-214: Fix misleading test title.The test uses
assertTypewithout@ts-expect-error, meaning it's verifying that passinggetNextPageParamwithoutpagesis allowed (per theInfiniteQueryPagesunion's{ pages?: never }branch). The title incorrectly says "should not allow".Apply this diff:
- it('should not allow passing getNextPageParam without pages', () => { + it('should allow passing getNextPageParam without pages', () => {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
packages/query-core/src/__tests__/queryClient.test-d.tsx(7 hunks)packages/query-core/src/types.ts(3 hunks)
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: DogPawHat
Repo: TanStack/query PR: 9835
File: packages/query-core/src/__tests__/queryClient.test-d.tsx:242-256
Timestamp: 2025-11-02T22:52:33.049Z
Learning: In the TanStack Query codebase, the new `query` and `infiniteQuery` methods support the `select` option for data transformation, while the legacy `fetchQuery` and `fetchInfiniteQuery` methods do not support `select` and should reject it at the type level.
📚 Learning: 2025-11-02T22:52:33.049Z
Learnt from: DogPawHat
Repo: TanStack/query PR: 9835
File: packages/query-core/src/__tests__/queryClient.test-d.tsx:242-256
Timestamp: 2025-11-02T22:52:33.049Z
Learning: In the TanStack Query codebase, the new `query` and `infiniteQuery` methods support the `select` option for data transformation, while the legacy `fetchQuery` and `fetchInfiniteQuery` methods do not support `select` and should reject it at the type level.
Applied to files:
packages/query-core/src/__tests__/queryClient.test-d.tsxpackages/query-core/src/types.ts
📚 Learning: 2025-08-19T03:18:18.303Z
Learnt from: oscartbeaumont
Repo: TanStack/query PR: 9564
File: packages/solid-query-devtools/src/production.tsx:2-3
Timestamp: 2025-08-19T03:18:18.303Z
Learning: In the solid-query-devtools package, the codebase uses a pattern of type-only default imports combined with typeof for component type annotations (e.g., `import type SolidQueryDevtoolsComp from './devtools'` followed by `typeof SolidQueryDevtoolsComp`). This pattern is consistently used across index.tsx and production.tsx files, and the maintainers prefer consistency over changing this approach.
Applied to files:
packages/query-core/src/__tests__/queryClient.test-d.tsxpackages/query-core/src/types.ts
🧬 Code graph analysis (1)
packages/query-core/src/__tests__/queryClient.test-d.tsx (2)
packages/query-core/src/queryClient.ts (1)
infiniteQuery(409-431)packages/query-core/src/types.ts (2)
InfiniteData(204-207)InfiniteQueryExecuteOptions(568-586)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Test
- GitHub Check: Preview
🔇 Additional comments (7)
packages/query-core/src/types.ts (3)
491-509: LGTM: QueryExecuteOptions introduces select support correctly.The new
QueryExecuteOptionsinterface properly introduces theselecttransformation flow via theTQueryDatageneric. The data flows asTQueryFnData(raw) →TQueryData(intermediate) →TData(final via select). ThestaleTimecorrectly usesTQueryDatasince staleness should be determined from the query's stored data, not the transformed result.
511-528: LGTM: FetchQueryOptions maintains backward compatibility.The refactor to make
FetchQueryOptionsan alias that omitsselectfromQueryExecuteOptionsis correct. PassingTDataas both the 3rd and 4th generics (TData, TData) ensures no transformation layer exists whenselectis omitted, maintaining the original behavior offetchQuery.
568-586: LGTM: InfiniteQueryExecuteOptions properly extends execute options.The type correctly:
- Omits
initialPageParamfromQueryExecuteOptions(which hasinitialPageParam?: never)- Re-adds it via
InitialPageParam<TPageParam>with the proper type- Uses
InfiniteData<TQueryFnData, TPageParam>as the intermediate data shape- Includes
InfiniteQueryPagesdiscriminated union to enforce the pages/getNextPageParam constraintpackages/query-core/src/__tests__/queryClient.test-d.tsx (4)
161-172: LGTM: Correctly verifies fetchQuery rejects select.The test properly uses
@ts-expect-errorto confirm that the legacyfetchQuerymethod does not support theselectoption, maintaining backward compatibility.Based on learnings.
229-239: LGTM: Correctly verifies query accepts select.The test confirms that the new
querymethod supports theselectoption for data transformation, usingassertType(without@ts-expect-error) to validate this is allowed.Based on learnings.
241-257: LGTM: Correctly verifies infiniteQuery accepts select.The test confirms that the new
infiniteQuerymethod supports theselectoption for transforming infinite query data, usingassertType(without@ts-expect-error) to validate this is allowed.Based on learnings.
328-336: LGTM: infiniteQueryOptions properly typed.The variable correctly uses
InfiniteQueryExecuteOptions<TData, TError>with defaults for remaining generics. ThegetNextPageParamcallback properly receiveslastPagetyped asTData.
| it('should not allow passing getNextPageParam without pages', () => { | ||
| assertType<Parameters<QueryClient['infiniteQuery']>>([ | ||
| { | ||
| queryKey: ['key'], | ||
| queryFn: () => Promise.resolve({ count: 1 }), | ||
| initialPageParam: 1, | ||
| getNextPageParam: () => 1, | ||
| }, | ||
| ]) | ||
| }) |
There was a problem hiding this comment.
Fix misleading test title.
The test uses assertType without @ts-expect-error, meaning it's verifying that passing getNextPageParam without pages is allowed. The title incorrectly says "should not allow".
Apply this diff:
- it('should not allow passing getNextPageParam without pages', () => {
+ it('should allow passing getNextPageParam without pages', () => {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| it('should not allow passing getNextPageParam without pages', () => { | |
| assertType<Parameters<QueryClient['infiniteQuery']>>([ | |
| { | |
| queryKey: ['key'], | |
| queryFn: () => Promise.resolve({ count: 1 }), | |
| initialPageParam: 1, | |
| getNextPageParam: () => 1, | |
| }, | |
| ]) | |
| }) | |
| it('should allow passing getNextPageParam without pages', () => { | |
| assertType<Parameters<QueryClient['infiniteQuery']>>([ | |
| { | |
| queryKey: ['key'], | |
| queryFn: () => Promise.resolve({ count: 1 }), | |
| initialPageParam: 1, | |
| getNextPageParam: () => 1, | |
| }, | |
| ]) | |
| }) |
🤖 Prompt for AI Agents
In packages/query-core/src/__tests__/queryClient.test-d.tsx around lines 271 to
280, the test title is misleading — it claims "should not allow passing
getNextPageParam without pages" while the body uses assertType (no
@ts-expect-error) which verifies the opposite. Rename the test title to
accurately describe the behavior (for example "should allow passing
getNextPageParam without pages") so the description matches the assertion.
| const cachedData = query.state.data | ||
|
|
||
| if (cachedData === undefined) { | ||
| return this.fetchQuery(options) | ||
| } |
There was a problem hiding this comment.
I get why this was removed (because staleTime: 'static' achieves the same thing), however, background refetching with revalidateIfStale was never triggered if we had no data in the cache, and right now, it’s the first thing that happens.
I guess it’s mostly fine because query.fetch will dedupe promises, but there is the edge-case where users pass cancelRefetch which would lead to to the first fetch being cancelled.
Not sure what a good way out here would be, except maybe not re-implement ensureQueryData with this.query rather than keep the current implementation ?
also since query now supports select, these functions also do transformation in case you’ve passed excess properties!
I think what we should do is leave ensureQueryData, fetchQuery and prefetchQuery alone for now and NOT have them call .query or .infiniteQuery under the hood.
| if (select) { | ||
| return basePromise.then((data) => select(data)) | ||
| } |
There was a problem hiding this comment.
we could just await the basePromise ?
| return basePromise.then((data) => select(data)) | ||
| } | ||
|
|
||
| return basePromise.then((data) => data as unknown as TData) |
There was a problem hiding this comment.
not sure why this is necessary :/
| initialPageParam: 1, | ||
| }) | ||
|
|
||
| const data = await new QueryClient().infiniteQuery(options) |
There was a problem hiding this comment.
since it works for useInfiniteQuery, it should also work for client.infiniteQuery()
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
packages/query-core/src/queryClient.ts (1)
428-450: Implementation delegates correctly, but consider type-safe alternatives to the cast.The method properly sets
infiniteQueryBehaviorbefore delegating toquery. Theas anycast on line 449 bypasses type safety—consider whether tighter generic constraints or a helper could eliminate it.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
packages/query-core/src/queryClient.ts(5 hunks)packages/query-core/src/types.ts(3 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: DogPawHat
Repo: TanStack/query PR: 9835
File: packages/query-core/src/__tests__/queryClient.test-d.tsx:242-256
Timestamp: 2025-11-02T22:52:33.071Z
Learning: In the TanStack Query codebase, the new `query` and `infiniteQuery` methods support the `select` option for data transformation, while the legacy `fetchQuery` and `fetchInfiniteQuery` methods do not support `select` and should reject it at the type level.
📚 Learning: 2025-11-02T22:52:33.071Z
Learnt from: DogPawHat
Repo: TanStack/query PR: 9835
File: packages/query-core/src/__tests__/queryClient.test-d.tsx:242-256
Timestamp: 2025-11-02T22:52:33.071Z
Learning: In the TanStack Query codebase, the new `query` and `infiniteQuery` methods support the `select` option for data transformation, while the legacy `fetchQuery` and `fetchInfiniteQuery` methods do not support `select` and should reject it at the type level.
Applied to files:
packages/query-core/src/types.tspackages/query-core/src/queryClient.ts
🧬 Code graph analysis (1)
packages/query-core/src/queryClient.ts (3)
packages/query-core/src/types.ts (6)
DefaultError(47-51)QueryKey(53-61)QueryExecuteOptions(491-509)InfiniteQueryExecuteOptions(568-586)FetchInfiniteQueryOptions(588-605)InfiniteData(204-207)packages/vue-query/src/queryClient.ts (1)
query(294-314)packages/query-core/src/utils.ts (1)
resolveStaleTime(101-113)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Test
🔇 Additional comments (4)
packages/query-core/src/types.ts (2)
491-509: LGTM! Well-designed interface for query execution options.The interface correctly separates
TQueryDatafromTDatato enable optionalselecttransformation, explicitly preventsinitialPageParamfor single queries, and provides clear documentation forstaleTimebehavior.
561-586: LGTM! Clean type composition for infinite query execution.The discriminated union for
InfiniteQueryPagesand the composition strategy forInfiniteQueryExecuteOptions(omitting theneverfield then adding the required version) correctly enforces that infinite queries must provideinitialPageParam.packages/query-core/src/queryClient.ts (2)
343-384: LGTM! Core query execution logic is sound.The method correctly handles stale-time checking, optional data fetching, and select transformation. The double cast
as unknown as TDataon line 383 is a TypeScript workaround when no select is provided (TData defaults to TQueryData), though it's safe in practice.
452-468: Fix: Missingoptions.behaviorsetup before delegation tofetchQuery.The
fetchInfiniteQuerymethod must setoptions.behaviorbefore delegating tofetchQuery, matching the pattern used ininfiniteQuery(lines 443-448) andensureInfiniteQueryData(lines 503-508). Without this, infinite query pagination will not work correctly.fetchInfiniteQuery< TQueryFnData, TError = DefaultError, TData = TQueryFnData, TQueryKey extends QueryKey = QueryKey, TPageParam = unknown, >( options: FetchInfiniteQueryOptions< TQueryFnData, TError, TData, TQueryKey, TPageParam >, ): Promise<InfiniteData<TData, TPageParam>> { + options.behavior = infiniteQueryBehavior< + TQueryFnData, + TError, + TData, + TPageParam + >(options.pages) return this.fetchQuery(options as any) }⛔ Skipped due to learnings
Learnt from: DogPawHat Repo: TanStack/query PR: 9835 File: packages/query-core/src/__tests__/queryClient.test-d.tsx:242-256 Timestamp: 2025-11-02T22:52:33.071Z Learning: In the TanStack Query codebase, the new `query` and `infiniteQuery` methods support the `select` option for data transformation, while the legacy `fetchQuery` and `fetchInfiniteQuery` methods do not support `select` and should reject it at the type level.
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/query-core/src/queryClient.ts (1)
428-450: Fix the type error and avoidas anyassertion.Two issues need to be addressed:
Pipeline failure (Line 443): The type error indicates that
QueryBehavior<TQueryFnData, TError, InfiniteData<TQueryFnData, TPageParam>, readonly unknown[]>is not assignable toQueryBehavior<TQueryFnData, TError, InfiniteData<TQueryFnData, TPageParam>, TQueryKey>. This suggests a mismatch in the query key type constraint.Line 449: The
as anytype assertion bypasses type safety and hides potential type errors. This indicates that the types don't align properly betweenInfiniteQueryExecuteOptionsandQueryExecuteOptions.The type system should properly model the relationship between these option types without requiring unsafe casts. Please investigate:
- Whether the
QueryExecuteOptionstype needs to be adjusted to properly accept infinite query options- Whether the generic constraints need to be refined to make the types compatible
- Alternative approaches that maintain type safety
#!/bin/bash # Check how behavior property is typed and used ast-grep --pattern $'behavior: QueryBehavior<$$$>'
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
packages/query-core/src/queryClient.ts(5 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: DogPawHat
Repo: TanStack/query PR: 9835
File: packages/query-core/src/__tests__/queryClient.test-d.tsx:242-256
Timestamp: 2025-11-02T22:52:33.071Z
Learning: In the TanStack Query codebase, the new `query` and `infiniteQuery` methods support the `select` option for data transformation, while the legacy `fetchQuery` and `fetchInfiniteQuery` methods do not support `select` and should reject it at the type level.
📚 Learning: 2025-11-02T22:52:33.071Z
Learnt from: DogPawHat
Repo: TanStack/query PR: 9835
File: packages/query-core/src/__tests__/queryClient.test-d.tsx:242-256
Timestamp: 2025-11-02T22:52:33.071Z
Learning: In the TanStack Query codebase, the new `query` and `infiniteQuery` methods support the `select` option for data transformation, while the legacy `fetchQuery` and `fetchInfiniteQuery` methods do not support `select` and should reject it at the type level.
Applied to files:
packages/query-core/src/queryClient.ts
🧬 Code graph analysis (1)
packages/query-core/src/queryClient.ts (3)
packages/query-core/src/types.ts (6)
DefaultError(47-51)QueryKey(53-61)QueryExecuteOptions(491-509)InfiniteQueryExecuteOptions(568-586)FetchInfiniteQueryOptions(588-605)InfiniteData(204-207)packages/vue-query/src/queryClient.ts (1)
query(294-314)packages/query-core/src/utils.ts (1)
resolveStaleTime(101-113)
🪛 GitHub Actions: PR
packages/query-core/src/queryClient.ts
[error] 443-443: Type 'QueryBehavior<TQueryFnData, TError, InfiniteData<TQueryFnData, TPageParam>, readonly unknown[]>' is not assignable to type 'QueryBehavior<TQueryFnData, TError, InfiniteData<TQueryFnData, TPageParam>, TQueryKey>'.
🔇 Additional comments (2)
packages/query-core/src/queryClient.ts (2)
28-28: LGTM!The new type imports support the
queryandinfiniteQuerymethod signatures correctly.Also applies to: 37-37
373-383: Verify data handling assumptions in the query method implementation.The technical concerns in the review are valid: when
isStaleis false,query.state.datacould beundefined(initialized withoutinitialData), and this would be passed to theselectfunction without a guard. The type signatureselect?: (data: TQueryData) => TDataexpects defined data, but the cast on line 375 (as TQueryData) doesn't guarantee it at runtime.However, test cases across the codebase show
selectalways receives properly typed, defined data—no scenario in tests passesundefinedto the selector. This suggests either:
- The scenario is prevented by caller contracts (e.g., always providing
initialDataor ensuring fetch completes first)- The stale-time logic prevents
isStale=falsewhen data is undefined- This is an edge case not covered by tests
Confirm whether adding a guard (e.g.,
if (!queryData) return queryData as TData) is necessary, or if the current design intentionally relies on caller responsibility to provide valid initial state.
| fetchInfiniteQuery< | ||
| TQueryFnData, | ||
| TError = DefaultError, | ||
| TData = TQueryFnData, | ||
| TQueryKey extends QueryKey = QueryKey, | ||
| TPageParam = unknown, | ||
| >( | ||
| options: FetchInfiniteQueryOptions< | ||
| TQueryFnData, | ||
| TError, | ||
| TData, | ||
| TQueryKey, | ||
| TPageParam | ||
| >, | ||
| ): Promise<InfiniteData<TData, TPageParam>> { | ||
| return this.fetchQuery(options as any) | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Avoid as any type assertion.
Line 467 uses as any when delegating to fetchQuery, which bypasses type safety. While this maintains the existing delegation pattern (based on past review comments indicating fetchInfiniteQuery should call fetchQuery), the type assertion suggests that FetchInfiniteQueryOptions and FetchQueryOptions aren't properly aligned.
Consider:
- Ensuring
FetchInfiniteQueryOptionsproperly extends or is compatible withFetchQueryOptionsso no cast is needed - Adding an internal helper that both methods can safely delegate to without type assertions
- If the cast is unavoidable due to the type structure, document why it's safe with a comment
#!/bin/bash
# Check the relationship between FetchInfiniteQueryOptions and FetchQueryOptions
ast-grep --pattern $'export type FetchInfiniteQueryOptions<$$$> = $$$'🤖 Prompt for AI Agents
In packages/query-core/src/queryClient.ts around lines 452 to 468, the
fetchInfiniteQuery implementation uses "as any" to call fetchQuery which
bypasses type safety; fix by ensuring FetchInfiniteQueryOptions is compatible
with FetchQueryOptions (update its declaration to extend or intersect the
FetchQueryOptions generic shape), or extract a private internal typed helper
that both fetchQuery and fetchInfiniteQuery call (with appropriate generic
bounds) so no cast is needed; if a cast is truly unavoidable due to type
constraints, replace "as any" with a narrower, justified cast and add a brief
comment explaining why the cast is safe.
2 participants
🎯 Changes
Implements #9135
fetchQueryandfetchInfiniteQuerytoqueryandinfiniteQueryfetch*aliases for the renamed methodsprefetch*methods withqueryinstead offetchQueryensureQueryDatamethods toquerywithstaletime: 'static'TODO when this is merged (I have stacked branchs for these)
✅ Checklist
pnpm run test:pr.🚀 Release Impact
Summary by CodeRabbit
New Features
selectoption in query and infinite-query flowsInfiniteQueryExecuteOptionsand a publicnoophelperChores
queryandinfiniteQuerywhile preserving legacy wrappers for compatibilityTests