Loading state for dependent queries recipe

[DannyDelott]

Following the recipe for dependent queries from the docs, is there an idiomatic way to get the loading state of the final query?

For example, if there is a fast query that depends on a slow query, how can we show a spinner while the two are loading?

Scenario

Given this hook

function useCustomQuery() {
  const slowQuery = useQuery({
    /* a slow query */
  });

  return useQuery({
    /* a fast query that depends on slowQuery */
    enabled: !!slowQuery.data,
  });
}

And a component that uses it:

const MyComponent = (props) => {
  const { data, isLoading } = useCustomQuery();

  // Given the implementation of useCustomQuery, we only 
  // render the spinner for the duration of the fast query. 
  if (isLoading) {
    return <Spinner />;
  }

  return (
    <div>{data.value}</div>
  );
};

We'll only see the spinner while the fast query is in a loading state.

Current approach

We have a pattern of forwarding the dependent query results to the caller in an array:

function useCustomQuery() {
  const slowQuery = useQuery({
    /* a slow query */
  });

  const customQuery = useQuery({
    /* a fast query that depends on slowQuery */
    enabled: !!slowQuery.data,
  });
  
  // always return as [FinalQuery, QueryResults[]]
  return [customQuery, [slowQuery, customQuery]];
}

Consumers can then apply "status predicates" to find out if a list of queries is loading.

const MyComponent = (props) => {
  const [{ data }, queryResults] = useCustomQuery();

  // Predicate util checks for any loading states in the list. 
  // Spinner now shows for duration of both queries.
  if (isLoading(queryResults)) {
    return <Spinner />;
  }

  return (
    <div>{data.value}</div>
  );
};

This pattern is verbose and leaky (callers can depend the list of dependent queries in weird ways), but it does solve the problem.

Is there a better way to go about this?

[TkDodo]

with custom hooks, I like to keep the interface that they expose identical or close to the standard react-query syntax, so that we have least-surprise with using them. So I would just "override" the returned isLoading and || them both:

function useCustomQuery() {
  const slowQuery = useQuery({
    /* a slow query */
  });

  const fastQuery = useQuery({
    /* a fast query that depends on slowQuery */
    enabled: !!slowQuery.data,
  });

  return {
    ...fastQuery,
    isLoading: fastQuery.isLoading || slowQuery.isLoading
  }
}

of course - what about the status field? and what about isError ? and all the other fields that we might need to join... I guess it depends on each use-case, I usually like to take this step by step 🤷 .

Also note that the second query will be in idle status (or isIdle will be true) for as long as it is disabled, so you can act on that as well without combining anything:

  const { data, isLoading, isIdle } = useCustomQuery();

  if (isLoading || isIdle) {
    return <Spinner />;
  }

this might even be easier for this case, because you can just return the second query as-is.

[DannyDelott]

Yeah idle is new to me conceptually, so I'm not sure if it's semantically the same as our combining approach. As you mention, if the slowQuery times out, then we'd render an infinite Spinner under the condition: isLoading || isIdle.