feat: enhance React Query integration with per-type query key support #2361

Armanio · 2025-09-10T18:15:14Z

Fix #2359

Status

READY

Description

Generate unique query keys for infinite vs regular queries

PS: I'm not sure if this edit requires a doc edit, if not, please correct me

Armanio · 2025-09-10T18:19:58Z

packages/query/src/index.ts

+${
+  !queryKeyMutator
+    ? queries
+        .filter(


reject all non unique queryKeyFnName for prevent generate duplication functions

Does this mean that the issue was already there?
Or has this change meant that there is now a possibility of duplication?

After the discussion, if we define this processing, insert a variable definition such as uniqueQueryKeys to make the nesting shallowe.

Does this mean that the issue was already there?

No, this is an introduced problem. This happens because each query type has its queryKeyFnName
For example QueryType.QUERY and QueryType.SUSPENSE_QUERY has same queryKeyFnName

Probably we need drop queryKeyFnName from queries array and use somewhat like

const queryKeyFnName = query.type === QueryType.INFINITE || query.type === QueryType.SUSPENSE_INFINITE ? camel(`get-${operationName}-infinite-query-key`) : camel(`get-${operationName}-query-key`) ```

Unfortunately, the simple solution didn't work.
We need an array of keys: one for regular queries, the other for infinite ones.
Therefore, we have to iterate through the array of queries to collect the required ones.

If we stick with the ternary solution I suggested above, we'll end up with duplicate keys.

Perhaps I'm approaching the problem incorrectly and there's a simpler way. If so, I'd appreciate any hints.

Armanio · 2025-09-10T18:27:29Z

packages/query/src/index.ts

              options: query?.options,
              type: QueryType.SUSPENSE_INFINITE,
              queryParam: query?.useInfiniteQueryParam,
+              queryKeyFnName: camel(`get-${operationName}-infinite-query-key`),


now each query type has own queryKeyFnName

melloware · 2025-09-11T11:21:15Z

this LGTM but i would like @soartec-lab to review also.

soartec-lab

Thanks for the changes. I added some comments.

soartec-lab · 2025-09-13T09:31:16Z

packages/query/src/utils.ts

+
+// Convert "param: Type" to "param?: Type" for queryKey functions
+// to enable cache invalidation without type assertion
+export const makeParamsOptional = (params: string) => {


Currently, we are not strictly extracting functions into utils.
There are also benefits to having functions exposed in the files you use, closer to the processing they are used in.
What was the reason for moving them here now?

I felt that this was a rather isolated and generic function and it didn't belong in the index file.
After all, the index file is too big and hard to understand.

soartec-lab · 2025-09-13T09:42:24Z

packages/query/src/index.ts

+    ${[
+      routeString,
+      query.type === QueryType.INFINITE ||
+      query.type === QueryType.SUSPENSE_INFINITE
+        ? `'infinite'`
+        : '',
+      queryParams ? '...(params ? [params]: [])' : '',
+      body.implementation,
+    ]
+      .filter((x) => !!x)
+      .join(', ')}
+    ] as const;


Wouldn't it be enough to just prepend the string to the array for infinate?

Wht not, i agree

Great, then let's just add a prefix for a more concise fix.

Added the prefix as you suggested

soartec-lab · 2025-09-13T09:45:50Z

packages/query/src/index.ts

+${
+  !queryKeyMutator
+    ? queries
+        .filter(


Does this mean that the issue was already there?
Or has this change meant that there is now a possibility of duplication?

soartec-lab · 2025-09-13T09:49:21Z

packages/query/src/index.ts

+${
+  !queryKeyMutator
+    ? queries
+        .filter(


After the discussion, if we define this processing, insert a variable definition such as uniqueQueryKeys to make the nesting shallowe.

soartec-lab · 2025-09-13T09:51:11Z

packages/query/src/index.ts

  return '{ signal }';
 };

+const generateQueryKeyImplementation = ({


By extracting the function, the distance between the declaration and the place where it is actually used has increased. This increases the burden of understanding the overall processing, so consider reverting it if there is no significant benefit.

Yes, I understand what you're talking about. However, I'll put in my two cents:
I thought that in this way I was actually increasing the clarity of the code and its maintainability
generateQueryImplementation is already a very large function

Now the generator functions are divided by type of responsibility:

soartec-lab · 2025-09-20T15:31:10Z

@Armanio
I agree that index.ts is verbose. It's also true that it makes it difficult for us to make changes.
Related to that, it's also true that the changes are difficult to understand.

So I'd like to separate feature additions and refactorings.
Could you just make the feature changes in this PR and do the refactoring in a follow-up PR? I'd be happy to do that.

Armanio · 2025-09-20T15:33:09Z

Of course! Look a great plan. Give me little more time 🤝

…support - Generate unique query keys for infinite vs regular queries

Armanio · 2025-09-27T03:38:10Z

@soartec-lab
Updated the branch to include the latest changes.
Removed unnecessary refactoring and kept only the necessary changes.

Armanio commented Sep 10, 2025

View reviewed changes

Armanio force-pushed the fix_infinity_query_key branch from 77f8f56 to 051e3b2 Compare September 10, 2025 18:26

Armanio commented Sep 10, 2025

View reviewed changes

melloware added the tanstack-query TanStack Query related issue label Sep 10, 2025

Armanio force-pushed the fix_infinity_query_key branch 2 times, most recently from 38cd852 to 24fc7d6 Compare September 10, 2025 21:08

melloware previously approved these changes Sep 11, 2025

View reviewed changes

melloware assigned soartec-lab Sep 11, 2025

melloware requested a review from soartec-lab September 11, 2025 11:21

soartec-lab reviewed Sep 13, 2025

View reviewed changes

soartec-lab added this to the 7.12.0 milestone Sep 13, 2025

soartec-lab added the enhancement New feature or request label Sep 13, 2025

Armanio dismissed melloware’s stale review via 027d6d4 September 27, 2025 03:27

Armanio force-pushed the fix_infinity_query_key branch from 24fc7d6 to 027d6d4 Compare September 27, 2025 03:27

feat(query): enhance React Query integration with per-type query key …

2ffac79

…support - Generate unique query keys for infinite vs regular queries

Armanio force-pushed the fix_infinity_query_key branch from 027d6d4 to 2ffac79 Compare September 27, 2025 03:35

melloware modified the milestones: 7.12.0, 7.13.0, 7.14.0 Sep 27, 2025

Uh oh!

feat: enhance React Query integration with per-type query key support #2361

Are you sure you want to change the base?

feat: enhance React Query integration with per-type query key support #2361

Uh oh!

Conversation

Armanio commented Sep 10, 2025 • edited by melloware Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Status

Description

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

melloware commented Sep 11, 2025

Uh oh!

soartec-lab left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

soartec-lab commented Sep 20, 2025

Uh oh!

Armanio commented Sep 20, 2025

Uh oh!

Armanio commented Sep 27, 2025

Uh oh!

Uh oh!

Armanio commented Sep 10, 2025 •

edited by melloware

Loading