[Suggestion] Add lazy evaluation interface for Suspense

[ellemedit]

I found some inefficient case react-query in Suspense mode. So I suggest a little changes.

case 1: queries are suspended by previous query!

const Product = ({ productId }) => {
  const productQuery = useQuery(['product', productId], fetchProductById, { suspense: true });
  const brandsQuery = useQuery('brands', fetchAllBrands, { suspense: true });

  return (
    <div>
      <ProductTitle title={product.title} />
      <ProductBrand product={productQuery.data} brands={brandsQuery.data} />
    </div>
  );
}

brandsQuery is not executed till productQuery is prepared. Because each useQuery throws suspender and it blocks function execution even if the queries are not dependent for each query.

So you can think about merging the fetch operation. But it cause problem.

case 2: unable to renders as you fetch

const Product = ({ productId }) => {
  const productQuery = useQuery(['product', productId], async (_, productId) => {
    const [product, brands] = Promise.all([
      fetchProductById(productId),
      fetchAllBrands(),
    ]);
    return combineProduct(product, brands)
  }, { suspense: true });

  return (
    <div>
      <Suspense fallback={<span>Loading product...</span>}>
        <ProductTitle text={product.title} />
      </Suspense>
      <Suspense fallback={<span>Loading brand...</span>}>
        <ProductBrand {...product.brand} />
      </Suspense>
    </div>
  );
}

Because the two operation are wrapped in a query, we can't divide rendering concerns. In above example, <ProductTitle /> keeps suspending even if fetchProductById result resolved.

solution (for me)

So I'm using wrapped useQuery in production, like:

// not actual hook, my version includes type annotation and more options. :)
const useResource = (...args) => {
  const query = useQuery(...args);
  return {
    ...query,
    read() {
      if (query.status === "loading" || query.isFetching) {
        throw query.refetch();
      } else if (query.status === "error") {
        throw query.error;
      }
      return query.data;
    }
  };
};

it is similar to official react document

example: https://codesandbox.io/s/intelligent-thunder-ir39b?file=/src/App.js

now the exact suspense guideline is unclear... but I think above problems can be common and official guideline interface is good at this moment. How about considering to add interface react-query? Let me know if there's what I misunderstand how react-query works.

If this idea accepted, I guess I can contribute this. Or welcome to discuss other edge cases.

[tannerlinsley]

My response to this use case is that if you expect sibling suspenders to fire and suspend simultaneously, you should put their queries in their own respective components and let SuspenseList do the work of parallelizing them.

I understand what you're proposing, but this would add significant overhead to the API for an edge case that is not intended to be solved with React Query itself.

[ellemedit]

I think <SuspenseList /> is not the solution. My understanding of <SuspenseList /> is how will <Suspense /> children reveals, not handle component's suspend status. It looks not helpful about concurrency of each component. (If I misunderstood, let me know)

Could you explain the edge cases? I haven't imagine overhead you said. some clues will be helpful!

[tannerlinsley]

Futhermore, if you have a view that uses multiple queries, but both must complete before it can be rendered, then you should use the queryCache.prefetchQuery method to trigger both queries to start fetching before you attempt to render the component.

[ellemedit]

Yes, you are right. My first attempt was also prefetching them. Maybe there was a problem. I will append the context if my memory back. sorry.