Buggy interaction between returning filtered data in the combine property for useQueries function

[skalidindi]

Describe the bug

I am trying to use the useQueries function to call a bunch of APIs in different regions. I expect some of them to give back 404 errors and thus I want to use the combine method to filter out only the successful methods.

However, I noticed that doing something like the following

useQueries({
    queries,
    combine: (results) => {
      // const data = results.filter((result) => result.isSuccess).map((result) => result.data);
      // console.log(results);
      return {
        isLoading: results.some((result) => result.isLoading),
        data: results.filter((result) => result.isSuccess).map((result) => result.data)
      };
    },
  });

where data is filtering out only the successful results causes isLoading to never settle on false and thus component stays stuck in the loading state forever.
However, if I remove the filter block, then it settles to false just fine.

Your minimal, reproducible example

https://codesandbox.io/p/devbox/old-monad-pyr3qf

Steps to reproduce

View at the code sandbox link.
Notice how loading stays stuck on loading state.
If you remove the filter then it works fine.
Also note that you need to have atleast one API be in an error state for this bug to show up.

Expected behavior

I expect the useQueries function to settle on isLoading after all calls have finished and thus all queries in the array should be isLoading false.

How often does this bug happen?

Every time

Screenshots or Videos

No response

Platform

• OS: MacOS
• Browser: Arc
• Version: 5.18.1

Tanstack Query adapter

None

TanStack Query version

5.18.1

TypeScript version

4.4.4

Additional context

No response

[TkDodo]

This is an interesting one, and took me some time to figure out, but I think I've got it. It's a problem with how we do smart property tracking (not so smart in this case).

We try to minimize re-renders by only re-rendering a component if it actually uses something that it is interested in. To do that, we keep track of what gets used, for each query. You can read more about this here: https://tkdodo.eu/blog/react-query-render-optimizations#tracked-queries

With useQueries, we also do this per query. But when you call .some on an array, it will eagerly abort if it gets a true hit, thus only invoking result.isLoading for the first query, which means when the loading state for the queries 2-4 changes, we don't re-render the component.

That + the .filter function, which will make sure that we track the data property will lead to only the data property being tracked. If you don't have the .filter function, we will have an empty set of properties to track, which means we're tracking all properties. That's why it works without filter, but not with it.

That's certainly a bug, but I'd need to dig into how to fix this. As a workaround, you can set notifyOnChangeProps: 'all' on your query to get a consistent result:

 queries: ids.map((id) => ({
   queryKey: ["post", id],
   queryFn: () => fetchPost(id),
   retry: false,
+  notifyOnChangeProps: "all",
 })),

If I don't find a fix, I will probably force set notifyOnChangeProps: 'all' if combine is specified on useQueries. This might run combine more often, but that's better than missing re-renders. We don't track the result object of useQueries anyways, so this option is not too useful if combine is specified.

[skalidindi]

Sounds good. Thanks for the quick reply, really appreciate it. I have read your blog before (really excellent resource) but I will brush up on it again.

[TkDodo]

I found a proper fix, please try out v5.24.7