Error being handled differently for API Routes (client-side navigation vs directly hit)

[raulfdm]

Hi folks...

I'm currently struggling a bit with Error handling for a route that is only supposed to "redirect".

I read the docs but I couldn't get the pieces together to solve this puzzle so I decide to come out to ask for help.

Problem

Consider the following route structure:

app/routes
├── index.tsx
└── project
    ├── $id.tsx
    └── index.tsx

/project/index.ts is a route that, once hit, gets the latest project ID and redirects to /projects/$id.tsx:

// routes/project/index.tsx
export async function loader() {
  try {
    const latestProjectId = await getNewestProjectId();

    return redirect(`/project/${latestProjectId}`);
  } catch (error) {
    console.log("Something went wrong :(");
    throw error;
  }
}

To cover possible errors on this route, I add both ErrorBoundary and CatchBoundary:

// routes/project/index.tsx
export function ErrorBoundary() {
  return <h1>ErrorBoundary ("app/routes/project/index.tsx")</h1>;
}

export function CatchBoundary() {
  return <h1>oh no Catch</h1>;
}

My struggle is that if the getNewestProjectId fails for some reason (like the endpoint is unavailable), there's no single error strategy. If I access it directly, I have one problem, if I access it via client navigation, I have another.

Client-side navigation

1. I access home page /
2. I click on the /projects link

Accessing directly

Here I just access the endpoint /projects directly and get this error:

---

Gotcha

As far I understood, when I hit /project, because there's no page being default exported, Remix doesn't know that it should render the "ErrorBoundary".

Questions

1. Is this an expected behavior? I mean, is it possible to have a consistent way of handling situations like this?
2. Do you recommend to, for routes like this, return an empty page component so it can reach the ErrorBoundary?
3. If that's expected, could we reference somewhere in the docs to make it clear that the CatchBoundary won't work for those cases?

Reproducible example

Tiny demo
https://user-images.githubusercontent.com/12464600/214328618-54a97017-41cd-4789-8fb3-a2c6d4aab3b7.mp4

repository

• https://github.com/raulfdm/remix-error-handling-problem

[kiliman]

The main issue here is that in projects.tsx, you commented out the default export (the UI component). When you make a full request (not via client link), Remix notices there is no default export and treats it as a resource route. Remix returns the raw response to the client for resource requests. If there's an error, it simply returns a status 500 Unexpected Server Error. Since resource routes are not intended to be part of the UI, they don't get wrapped in <ErrorBoundary>.

When you navigate via <Link>, Remix will make the client side fetch request and appends the _data=route_id search param. Remix then treats this as a data request and calls the loader. If there's an error, it will return the error in the JSON payload, and Remix will render that in the <ErrorBoundary>.

So in this case, Remix is working as designed, although a little confusing.

[kiliman]

In your sample project, if you uncomment the default export you'll see that it works the same in both cases: direct and client-side.

[raulfdm]

I came up to this conclusion as well.

Thanks for clarifying the Remix side of it. Though, does that mean that every time we have a route that redirects a user like this one, we MUST export default a component that renders nothing? If so, should this be documented? I'm asking because it was tricky to reason why this happened.

[kiliman]

The rule of thumb is that if your route is involved in UI, it should always contain a default export, especially if you want an <ErrorBoundary>.

It should probably be called out here in the docs. @ryanflorence

https://remix.run/docs/en/v1/route/component

[ZeldOcarina]

How would you handle errors in a resource route? Like in Express you would call next(err), how does it work in Remix?

[rjvim]

I use Remix to server api resource routes, in this case imaging api endpoints called via postman, so there is no UI component. I was expecting I can handle errors using handleError but unfortunately though the function is called with error object which is thrown downstream, I am unable to return the error response using handleError function, whatever I return is not used.

Instead I get an generic error:

Unexpected Server Error

[object Object]

I am not even sure how to expand [object Object], how to override this response and generate our own?

I think it's similar to question asked by @ZeldOcarina

[ZeldOcarina]

What I ended up doing is adding my own try/catch blocks inside the action and returning a json response in the err with the appropriate status.
Since I am using the Express adaptor for complex API routes I am also just using plain old Express routes. Express still rocks in 2024 for APIs imo, it's the most feature-complete to build those!
Remix shines in UI components management and simple data fetching connected to the routes, when you have one route needing data from several different api endpoints, I found myself having a better dev experience with decoupling the API and using Express. My take..

[devbytyler]

Would still love some guidance on this! How do we handle resource routes returning errors? I found this blog post about using fetchers, but it would nice to have something a little more built-in.

https://jankraus.net/2024/09/06/downloading-files-in-remix-with-usefetcher-hook/