Relationship between data existence guarantees in useSuspenseQuery and the select option

[flex-kwoncheol]

Let's take a look at the example below.

function Page() {
  const { data } = useSuspenseQuery({
    queryKey: ['someKey'],
    queryFn: () => 'data',
    select: queryData => {
      if (queryData) {
        throw new Error('error');
      }
      
      return queryData;
    }
  });

  return (
    <div>
      Data: {String(data)} {/* Data: undefined */}
    </div>
  );
}

The return type of useSuspenseQuery says that the data always exists, but the example above shows that there are times when the data is undefined.

Is this type structure intended? If it is intended, I'm also wondering in what sense we should understand that the return type of useSuspenseQuery guarantees that the data is defined.

FYI

• maybe related with issue#5878
• (updates) Here's the example(codesandbox).

[TkDodo]

not sure why you would throw an error in select, but even if you do, the query would go into error state, and since suspense queries have to use error boundaries, the boundary would be shown instead of the component. So I don't think that you can reach the Data: undefined part you're showing.

So please show a runnable reproduction where data is actually undefined in the component because I don't think that's what really happens.

[flex-kwoncheol]

The context in which the select callback is executed is wrapped in try catch syntax, so no error is thrown during render and therefore no error propagates to the closest ErrorBoundary.

Here's the example(codesandbox).

[flex-kwoncheol]

not sure why you would throw an error in select,

I think it's possible that the logic (e.g. parsing logic) performed within the select callback could somehow cause a runtime error.

[TkDodo]

Thanks for the example.

it's wrapped in a try/catch that catches the error and then subsequently sets the query state to error:

query/packages/query-core/src/queryObserver.ts

Lines 544 to 549 in 81e1f2c

	if (this.#selectError) {
	error = this.#selectError as any
	data = this.#selectResult
	errorUpdatedAt = Date.now()
	status = 'error'
	}

error boundary handling is done on component level, so it should work the same as if the queryFn returned a rejected promise.

---

So I looked into it a bit and found out what the problem is. select runs on observer level - each useQuery instance can have its own transformation. In your scenario, the query itself that is stored in the cache is in success state. If you use the same query in another component with a select that doesn't throw, you'd get that data.

For suspense, we have implemented throwOnError in a way that we only throw if the data in the cache is undefined:

query/packages/react-query/src/suspense.ts

Lines 11 to 19 in febbde6

	export const defaultThrowOnError = <
	TQueryFnData = unknown,
	TError = DefaultError,
	TData = TQueryFnData,
	TQueryKey extends QueryKey = QueryKey,
	>(
	_error: TError,
	query: Query<TQueryFnData, TError, TData, TQueryKey>,
	) => query.state.data === undefined

This avoids throwing "background errors" (where a previous fetch succeeded) to error boundaries. So in your case, you have data in the cache, which is why we don't throw to the boundary, but the data for your observer is undefined, which is why we get undefined.

I need to think about what to do in this case. The suggestion is still to have select be a pure function that always returns something and doesn't throw errors.

[flex-kwoncheol]

Thank you, I now understand the current design structure. Then it seems that in the current structure, when using useSuspenseQuery with select, we should keep in mind that data can be undefined - because it would be very difficult to mechanically guarantee the purity of select.

The reason I think this is dangerous at the moment is because it's hard to debug: the part of the code that causes the runtime error is probably where you consume the data returned by useSuspenseQuery, which will access the data in an unsafe way because it thinks the data is defined. Eventually, you'll get a TypeError at runtime, but the error breadcrumb of the TypeError object doesn't lead to the error inside the select callback - I've added this case to the example codesandbox and commented it out.

Thanks anyway. Let me know if you need any more input.

[teogeos]

Hello people 🙂

I have come across this issue and wanted to give you my example of why I needed a select/suspense that throws to error boundaries.

I'm making a product page myapp.com/products/product-id. If the user tries to load the page with a product-id that doesn't exist, I need to show a 404 page. Problem is, my backend does not have a productById endpoint. What it has is a listProducts endpoint that takes a sql-like filter. So I wanted to simulate a productById endpoint like such:

function productByIdOptions(id: string) {
  return queryOptions({
    ...listProductsOptions(makeFilterWhereIdIn([id])),
    select: (listProductsResponse) => {
      // If there is a product with this ID it will be the only one in the response.
      const [product] = listProductsResponse.products;
      // Otherwise the array will be empty.
      if (product === undefined) throw new ErrorNotFound("Product Not Found");
      return product;
    }
  });
}

Then I use it like so:

function ProductPage() {
  const { productId } = useParams();
  const { data: product } = useSuspenseQuery(productByIdOptions(productId));
  // ...
}

If the product doesn't exist, I expected the error to be bubbled by useSuspenseQuery to my error boundary that would display the 404 page.

This seemed like the most straightforward and intuitive solution to my needs. It allows me to get what I need without having to define a whole new query options and query key, and still benefit from any invalidation to listProductsOptions.

It's counterintuitive that useSuspenseQuery just swallows this error, especially since data is now undefined at runtime although typescript thinks it's a Product.

What approach would you recommend instead?

[TkDodo]

I think you would have to handle it on component / custom hook level:

• return null from select
• throw ErrorNotFound in the component / the custom hook if you get null

[teogeos]

Thanks for your help.

Right, but one reason why I wanted a reusable query options function is that there are places where I'm using productByIdOptions with useSuspenseQueries to suspend on several queries without waterfalls, which I'm not sure I can with a custom hook.