Array of queries hook

[krashdifferent]

Problem:
I have a use case were a component would ideally consume a dynamic number of queries. For example, building a table where each column is populated by data from different queries but the user can select from a large list which columns will be populated at any one time. Ideally the data for each column would be queried individually in the parent component and passed to the table together, but the number of hooks within a component needs to be constant.

Is there a clean way to do this with the current API?

Current work arounds I've tried:

• Use a single useQuery with a fetching function that behind the scenes can dynamically fire all the necessary fetch calls based on the user selection. The downside with this is if the user removes or adds a single column, the query key doesn't match and all of the data needs to be refetched even if some sub-queries aren't stale.

• Move the useQueries into the columns directly or other separate components so they mount individually. Here the downsides are either limitations on how we can implement the table or hard to read and manage code.

Proposed feature:
Assuming I am not missing another way to do this, either a new hook useQueryArray or expansion of useQuery that accepts an array of keys and functions that are each individually cached.

[tannerlinsley]

From what you've described, this appears to be the classic "I want to use React hooks in array-mode", which we've definitely all been in before.

99.9% of the time, I feel the answer to this predicament is to render hook usages into multiple components and compose their results post-render, but there are definitely edge cases here and plenty of tradeoffs. However, it's the best solution we have currently since there is no great way to useMapHooks(item => useQuery(item), items). That would be really great, but trust me, I've been down that road and while I did get something to work more or less, it ended up complicating my code much more than I expected. For the time being, React Query will likely not get the feature you're talking about, since the library itself uses hooks, it's bound by the same mechanics you are and would require massive amounts of rearchitecting to even get somewhat close to what you're describing. The return on investment would not be worth it and would likely degrade the rest of the library in both performance, size and API complexity.

To solve your specific problem for today, I would suggest three possible solutions:

• Be okay with multiple columns info being requested even though you only need one. Adjust your memoization/consumption of those column infos to only update if they are new. This will keep things drastically simple and probably let you move forward faster.
• Compose your column info fetcher queries into multiple components that don't render anything and instead pass them a prop that allows them to report their results back up to the parent component, then compose their results in the parent component into a single array of columns.
• Create your own little "cache" to hold your list of already-fetched column information, then combine your fetching logic into a single query. Use your custom cache object to fill in the slots in that array when the data is available and also keep it up to date by clearing the cache as often as you see fit. I would consider this a last resort, since you would essentially start managing your own custom cache, which is exactly what React Query is meant to do for you. If you do get here, I would suggest weighing the benefits your getting with React Query here overall. It may be one edge case where React Query's caching/fetching strategy isn't a good fit, which is fine.

Hope this helps!

[krashdifferent]

Thanks for the feedback. More or less confirms the current workarounds I've been exploring are the best options. Having not looked more closely I was hopping the underlying cache implementation would be compatible with a request array. We will see if full re-fetching impacts user experience enough to split things out into components. We are undertaking a significant refactor and moving to react-query addresses a lot of the undying issues behind the refactor so if we have to be a little awkward for this one feature it's probably still worth it. Thanks for the library!

[mryechkin]

Hey @krashdifferent - if you don't mind me asking - did you end up solving this problem, and if so - how?

I'm running into this scenario as well, and would love to hear some tips if you have any. Thanks!

[krashdifferent]

@mryechkin - I did not find a solution significantly different than those mentioned above. I still feel this could be solved with a change to the API but would probably require significant effort. The best is probably to try to push each useQuery call lower in the component hierarchy so you don't need an array at all. Try to fetch the data as close as possible to where its being displayed even when it feels like you will be querying the data in multiple places. The cache makes this efficient. However when that's not possible, the basic approaches I've taken to the multiple calls problem are:

• Create a custom fetching function that parses the query key into multiple fetch calls. Basically you can just make the query key an array and the fetch function loop on the array. This does mean all the data will be re-fetched every time a new element is added to or removed from the array; however, in practice this hasn't been a huge performance problem in a lot of my use cases. It looks usePaginatedQuery might get deprecated but you can use the resolvedData from that to maintain the previous data while new elements load. This approach is probably the most straight forward to implement.

• Another approach is to create components that don't render anything but manage the queries as tannerlinsley suggests above. For me this meant creating two helper components. The first is just a wrapper around useQuery. It takes query keys and a callback function as props. useEffect is used to trigger the callback whenever the return from useQuery updates. The second component renders an array of the useQuery wrapper components. It takes the combined query keys and another callback as props. To use multiple calls then you just need to drop this second component anywhere in your render, pass it your query keys and listen to the callback for data updates. It's not as smooth as a simple hook call but it's not too bad once you get use to it. In practice I have the second wrapper display an "updating" icon whenever it's fetching which makes it feel more natural to place.

• Finally something I think might work is abusing useInfiniteQuery. I haven't tried this but since you can pass new query keys with each "next" call, there is nothing that actually requires this to be the next page in paginated data. You could just string together all of the query keys you wish to aggregate. Again I haven't tried this so I am not sure how messy the logic will get in managing the array of queries.

One note, while it's easier to explain thinking about just building an array from multiple queries, the actual concatenation/aggregation logic could be more complex with either of the above. In my use case, I'm actually building a nested object hierarchy rather than just concatenating arrays.

Hope this helps!

[krashdifferent]

@mryechkin - TL;DR:

• when you can just push useQuery lower in the component hierarchy and avoid the issue.

• Using an array as a query key and a custom fetch that loops on the array is a fast to implement solution that comprises cache granularity (and possibly makes invalidation after mutations more complicated).

• Creating components that wrap useQuery ultimately solves the problem and gives cache granularity but makes the API slightly less intuitive to use.

[krashdifferent]

One final comment. If you are going to be doing mutations as well, you need to make sure the correct query keys get invalidated. This is the biggest issue when creating a fetch function that accepts an array of query keys. Follow the invalidation from mutations docs and make sure to invalidate any overlapping query keys arrays.

[mryechkin]

@krashdifferent that's super helpful, thank you! 🙏

I'll look into those options more. Have a feeling that I'll settle on the first approach for simplicity's sake.

My original thinking was something like this (simplified for illustration purposes.. in my actual app I have an api client that wraps these fetch calls more elegantly and injects auth headers, etc.):

const fetchData = async () => {
  const res = await fetch('my-api/data');
  const data = await res.json();
  const otherRes = await fetch(`my-api/other-data/${data.id}`);
  const otherData = await otherRes.json();
  return {
    ...data,
    ...otherData,
  };
};

const Component = () => {
  const { isLoading, error, isError, data } = useQuery('my-data', fetchData);
  // rest of component code
}

Where data.id is something I need to retrieve from the initial fetch, and then aggregate the additional data for the my-data query. Am I completely off base here? Still quite new to react-query so want to make sure I'm not doing something stupid

[tannerlinsley]

Not sure if everyone here knows, but v3-beta already has a useQueries hook implemented: https://react-query-beta.tanstack.com/guides/parallel-queries#dynamic-parallel-queries-with-usequeries

Pretty sure that solves this problem, right?

[mryechkin]

Hi @tannerlinsley - thanks for following up on this. That's great to hear!

For my specific case above, it looks like the way to go is actually with dependent queries - I hadn't realized that was already available! Thanks for pointing in the right direction. I can definitely see myself using that useQueries hook in the future as well, though 👌

[krashdifferent]

@tannerlinsley - I hadn't had a chance to look through everything with v3 yet. Thanks for paying attention here and updating us! I might have to delay the next refactor I had planned around this issue until v3 is production ready. This looks exactly like what I've been hoping for. Much appreciated!

@mryechkin - I agree, looking at what you are proposing, even with the possibility of useQueries, using dependent queries is probably the way to go in your case.

[ianstormtaylor]

@tannerlinsley can I just say… thank you for useQueries. I've been looking at different React fetching libraries and none of them seem to have solved this super basic need, and I originally thought that react-query hadn't solved it either until I dug deeper. Having an API that accepts a simple array of configs is exactly what I was looking for in every other library—very simple solution to an obvious problem. Thanks!

[ianstormtaylor]

@tannerlinsley actually, I spoke slightly too soon. I was expected the result of useQueries to be an "aggregated" result instead of an array of results. I can see why the array of results is easier to implement, but working with it seems very convoluted.

Instead I'd assume that result.error would be an aggregated error—ie. the first error found if any. And result.data would be an aggregated array of data. And other things like result.isFetching would be true if any of the queries were still fetching, etc.

Without that aggregation step, I think using the results values when rendering a component is hard. If there's a need for the non-aggregated value, maybe the aggregation is a utility function that ships with react-query. For example:

const aggregateQueries = queries => {
  const error = queries.find(q => q.error).error
  const isFetching = queries.some(q => q.isFetching)
  const data = !error && !isFetching && queries.map(q => q.data)
  ...
  return { data, error, isFetching, ... }
}

(Writing that utility correctly is easy to mess up, so I don't think it makes sense to force userland to implement it.)

[tannerlinsley]

I’ll consider this before we ship v3 👍

[ianstormtaylor]

@tannerlinsley thanks! I just thought about it too, and I think useQueries would be most useful if it always returned the aggregate result, with an extra property of result.queries if people really need to get into the details—because using the aggregated error/isFetching/etc. properties is going to be the 90% case I think.

Any idea for when V3 ships?