feat: prefix infinite queries differently to "normal" queries?

Describe the feature you’d like to request

Currently, the cache gets a bit messed up if you use an endpoint the with .useInfiniteQuery() in one part of the app and .useQuery() in another.

Describe the solution you’d like to see

Currently, we store cache keys as [pathArray, input]-tuple

Maybe, we should store it as ['query' | 'infinite', pathArray, input]-tuple?

Or a [pathArray, 'query' | 'infinite', input]-tuple?

Desribe alternate solutions

Not doing it

Additional information

No response

👨‍👧‍👦 Contributing

• 🙋‍♂️ Yes, I’d be down to file a PR implementing this feature!

[TkDodo]

Given key: [ [‘post’, ‘byId’], { type: “query”, input: 1 } ]

invalidateQueries([ [‘post’, ‘byId’], { input: 1 } ]) would invalidate that key even if we don’t define the type?

That’s exactly right. Objects have no order so the partial matching will work as you want to here. I’m going into details why the object is pretty good for query keys: https://tkdodo.eu/blog/leveraging-the-query-function-context

[TkDodo]

// Query key to invalidate all queries and infinite Queries with an input of `userId:10`
[ ["post"], { input: { userId:10 } } ]  // ✅❓// I think would work!

// Query key to invalidate only queries with an input of userId:10
[ ["post"], { type: "query", input: { userId:10 } } ] // ✅❓

yes, those two would work.

I also thought about having one object, but I thought that we then wouldn’t be able to allow having type provided from the params. Having the input be a separate entry in the object would solve that nicely I think 👍