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?

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

0 reposts1 like

Are you open to a contribution around this? At the time I wasn’t sure whether this is aligned with your idea and obvs queriesOptions is a terrible name … 😅

Yeah we'll have to see. There aren't really any top level options other than combine. Have you tried building it in user-land ?

Only half-heartedly to be honest. It was originally part of a refactoring that got scrapped but the first tries showed that it won’t be simple to infer the right types. I’ll take this thread as motivation to look at it again tomorrow though 🚀