Post

📚 Creating thin abstractions is easy, until you’re trying to build them on top of functions that heavily rely on generics. Then it can quickly turn into a nightmare. I wrote about the tradeoffs of wrapping useQuery and why type inference makes this trickier than it looks.

tkdodo.euCreating Query AbstractionsBuilding reusable abstractions on top of libraries that rely on type inference can be deceptively difficult, which is why we need better ways to build those abstractions ...

13 reposts74 likes

right, it's pretty similar to useQuery / useQueries, right? Any plans on having queryStateOptions that can be passed to both useQueryState and useQueryStates ?

The only common options between the two is the Options type (shallow, history, limitUrlUpdates etc), which isn’t generic. What I started working on with the unified API might flip the problem on its head, but it needs a little more work before I can ship a preview that works with both hooks.

Great post as always. And I don't even use TanStack Query 😅 Still gives me ideas for when/if I want to abstract on top of Apollo Client's useQuery

That’s great and matches my experience 100%. One thing I am curious about is how you see using custom hooks around useQueries, because there is no queriesOptions API that allows for easy sharing multiple queries?

The canonical use-case for useQueries is to map over a dynamic array of items and make “the same” fetch with each entry, so it would just be one queryOptions.

If you use it with static length entries, this still works: const [invoice, todos] = useQueries({ queries: [invoiceOptions(1), allTodoOptions()] }) what would you need `queriesOptions` for ?

What we are missing is a way to share multiple queries together with the combine function. QueryOptions allows to share the whole singular payload (incl. select) but there is no easy way (type-wise) to achieve the same for multiple queries (incl. combine), which is the single source for custom hooks

incl.selectincl.select