trpc: 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!

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 15 (10 by maintainers)

Most upvoted comments

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 on Nov 13, 2022

// 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 👍

TkDodo on Nov 12, 2022

Can you use the same endpoint for normal and infinite queries? They do have different structures. They also definitely shouldn’t share the same query key…

TkDodo on Nov 8, 2022