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 ...

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?

0 reposts1 like

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