Single Fetch throwing response does not work

[timvandam]

Reproduction

https://stackblitz.com/edit/remix-run-remix-ndbnrb?file=app%2Froutes%2F_index.tsx,app%2Froot.tsx,tsconfig.json

System Info

System:
    OS: macOS 14.3
    CPU: (16) arm64 Apple M3 Max
    Memory: 229.22 MB / 64.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.11.1 - ~/.nvm/versions/node/v20.11.1/bin/node
    npm: 10.2.4 - ~/.nvm/versions/node/v20.11.1/bin/npm
    pnpm: 9.5.0 - ~/.nvm/versions/node/v20.11.1/bin/pnpm
  Browsers:
    Chrome: 127.0.6533.72
    Safari: 17.3

Used Package Manager

npm

Expected Behavior

Loader states should always stay consistent. E.g. useLoaderData<typeof loader> should always contain the latest valid loader data

Actual Behavior

Loader state isnt consistent when using throw response with single fetch. It becomes undefined unexpectedly leading to destructuring errors (see stackblitz)

[brophdawg11]

If you scroll, up in the console you will see this error after submitting:

You cannot useLoaderData in an errorElement (routeId: root)

This is standard behavior in all Remix routes. When an ErrorBoundary is rendering, you cannot use useLoaderData because it may have been the loader that threw the error so it could be undefined and then the types would be incorrect.

In your case, you have a useLoaderData in the root Layout which works fine on initial load. Then when you submit from the child route and it throws, that error bubbles up to the default ErrorBoundary which renders inside the Layout - and that call of useLoaderData fails and logs the error.

This is a common enough occurrence that there's a section in the docs, see the "A note on useLoaderData in the Layout Component" section in the root route docs.

If you need to display root loader data in Layout, then it's best to use useRouteLoaderData("root") which will include undefined in the types and force you to be defensive in case it was the root loader that threw the error.

[timvandam]

@brophdawg11 Thanks for your explanation, however, I am throwing the response stub which per the docs is a way to the short circuit actions/loaders to immediately respond to the incoming request. So what is happening here is that an error is incorrectly thrown by Remix, while it should have just sent a normal response

[brophdawg11]

So what is happening here is that an error is incorrectly thrown by Remix

How so? Your code is throwing the response stub - and any time you throw anything from a loader/action you trigger an ErrorBoundary.

Can you point to the section of the docs that is causing the confusion?

[timvandam]

So what is happening here is that an error is incorrectly thrown by Remix

How so? Your code is throwing the response stub - and any time you throw anything from a loader/action you trigger an ErrorBoundary.

Can you point to the section of the docs that is causing the confusion?

That is not the behavior in non-single-fetch mode when throwing Response instances, right? E.g., throw redirect(). For Single Fetch, the docs state:

You can also throw these response stubs to short circuit the flow of your loaders and actions:

export const loader = defineLoader(
  ({ request, response }) => {
    if (shouldRedirectToHome(request)) {
      response.status = 302;
      response.headers.set("Location", "/");
      throw response;
    }
    // ...
  }
);

(https://remix.run/docs/en/main/guides/single-fetch)

[brophdawg11]

Redirects are different than errors since you're telling the router to navigate to a new route, as opposed to informing it of an error on the current route.

You're not throwing a redirect in your reproduction though - you're throwing a response stub with a 400 status. Without single fetch, that's equivalent to throw json({ error: "broken" }, { status: 400 }) which would trigger the ErrorBoundary in the same way.

[timvandam]

Redirects are different than errors since you're telling the router to navigate to a new route, as opposed to informing it of an error on the current route.

You're not throwing a redirect in your reproduction though - you're throwing a response stub with a 400 status. Without single fetch, that's equivalent to throw json({ error: "broken" }, { status: 400 }) which would trigger the ErrorBoundary in the same way.

You're right, I've only ever thrown with redirect before so didn't realize it worked this way. I notice though that single fetch's types override useRouteLoaderData always return something, i.e., it removes the | undefined from the return type (see

remix/packages/remix-react/future/single-fetch.d.ts

Lines 27 to 29 in ac747ff

	export function useRouteLoaderData<T extends Loader>(
	routeId: string
	): Serialize<T>;

). This seems inconsistent with this behavior

Edit: after testing this out it seems like useRouteLoaderData is now always set, so while useLoaderData becomes undefined on error useRouteLoaderData retains its value from before the error

[brophdawg11]

it removes the | undefined from the return type

Ah thanks for pointing this out - this is a bug. In your case useRouteLoaderData("root") will always be defined but if you put an invalid route id or a non-mounted id in there it would be undefined - got this fixed in #9796 👍

[timvandam]

How exactly is the behavior different between the two, and for what reason? It’s not clear from the docs. I only seitched to it for the | ubdefined and was surprised it never became undefined during errors unlike useLoaderData

[brophdawg11]

useLoaderData is the happy path. Because you're using it in the specific route and that route will only ever be rendered after the loader has completed successfully - it should always return data. That's why we don't allow it in error boundaries - because we cant guarantee the data will be there. And thus it's typed accordingly, without | undefined.

useRouteLoaderData lets you ask for any route's data - and since we have no idea if the route you're asking for is mounted, it can be undefined - and you can then use that as the workaround for the error boundary because the typings are accurate.