Root loader not being called in CatchBoundary #5186

kevinwolfcr · 2022-07-15T18:09:37Z

kevinwolfcr
Jul 15, 2022

What version of Remix are you using?

1.6.4

Steps to Reproduce

Export something from your root loader, and try to read the data returned by that loader in the CatchBoundary.

import { json, LoaderFunction } from "@remix-run/node"
import { useMatches } from "@remix-run/react"

import { getBaseURL } from "~/utils/seo"

export const loader: LoaderFunction = ({ request }) => {
  return json({ baseUrl: getBaseURL(request) })
}

const Root: React.FC = () => {
  console.log(JSON.stringify(useMatches(), null, 2))
  return <div>Root</div>
}

export const CatchBoundary = () => {
  console.log(JSON.stringify(useMatches(), null, 2))
  return <div>Catch</div>
}

export default Root

Navigate to a non-existing route.

Expected Behavior

This should be logged to the console (taken from an existing route).

[
  {
    "id": "root",
    "pathname": "/",
    "params": {},
    "data": {
      "baseUrl": "http://localhost:3000"
    }
  }
]

Actual Behavior

This was logged to the console (taken from a non-existing route).

[
  {
    "id": "root",
    "pathname": "",
    "params": {}
  }
]

kiliman · 2022-07-16T14:26:56Z

kiliman
Jul 16, 2022
Maintainer

Depending on if this is a document request or a data request, Remix will work slightly different. If you're navigating to a non-existent route on a document request (full page), Remix throws the new Response(404) before it runs any loaders, so useMatches will not have the root data (nor any other data in the route).

However if you've already rendered the initial document and making a client-side navigation to a non-existent route, Remix will still throw the 404 response, but this time, useMatches still has the original route data, so that is what is returned.

You can verify this behavior by typing in the URL http://localhost:3000/not-found. It should not have root data.

Add a link in your route to <Link to="not-found"/>. Click on it and you'll see that root data is present, since the current route had already rendered.

I'm pretty sure this is by design. So I would not rely on that data being present in the catch boundary, since that's typically used to indicate some type of error.

0 replies

revelt · 2022-07-18T08:17:22Z

revelt
Jul 18, 2022

This bug/feature has been since the beginning; in practice, for example, it means our 404 pages can't show the correct theme. It would be nice if loaders were called in catch boundaries.

0 replies

kiliman · 2022-07-18T12:42:54Z

kiliman
Jul 18, 2022
Maintainer

The only time you won't get root data is if the error/catch boundary is hit on a full document request. My recommendation is to handle this case in the handleRequest export of entry.server.

export default function handleRequest(
  request: Request,
  responseStatusCode: number,
  responseHeaders: Headers,
  remixContext: EntryContext
) {

  if (responseStatusCode === 404) {
    // fetch theme from (cookie?, host?)
    // render page with catch boundary
    const markup = renderToString(...)
    return new Response("<!DOCTYPE html>" + markup, {
      status: responseStatusCode,
      headers: responseHeaders,
    });
  }

0 replies

kevinwolfcr · 2022-07-19T17:07:51Z

kevinwolfcr
Jul 19, 2022
Author

Depending on if this is a document request or a data request, Remix will work slightly different. If you're navigating to a non-existent route on a document request (full page), Remix throws the new Response(404) before it runs any loaders, so useMatches will not have the root data (nor any other data in the route).

However if you've already rendered the initial document and making a client-side navigation to a non-existent route, Remix will still throw the 404 response, but this time, useMatches still has the original route data, so that is what is returned.

You can verify this behavior by typing in the URL http://localhost:3000/not-found. It should not have root data.

Add a link in your route to <Link to="not-found"/>. Click on it and you'll see that root data is present, since the current route had already rendered.

I'm pretty sure this is by design. So I would not rely on that data being present in the catch boundary, since that's typically used to indicate some type of error.

@kiliman yeah, as I see it, it is like that by design. The funny thing is that the root loader doesn't get called only when a 404 statusCode is thrown, imo, it should be called always, since it is part of the App Root, and not specific to any page.

This bug/feature has been since the beginning; in practice, for example, it means our 404 pages can't show the correct theme. It would be nice if loaders were called in catch boundaries.

@revelt have you found any workaround? maybe doing something in entry.server.ts?

The only time you won't get root data is if the error/catch boundary is hit on a full document request. My recommendation is to handle this case in the handleRequest export of entry.server.

export default function handleRequest(
  request: Request,
  responseStatusCode: number,
  responseHeaders: Headers,
  remixContext: EntryContext
) {

  if (responseStatusCode === 404) {
    // fetch theme from (cookie?, host?)
    // render page with catch boundary
    const markup = renderToString(...)
    return new Response("<!DOCTYPE html>" + markup, {
      status: responseStatusCode,
      headers: responseHeaders,
    });
  }

@kiliman how would you recommend me to get the domain and pass it down to be available to put on my metatags? Is there a way to modify that remixContext with some data and read it from my route components / catch boundaries / error boundaries?

0 replies

sergiodxa · 2022-07-20T17:15:43Z

sergiodxa
Jul 20, 2022
Maintainer

This bug/feature has been since the beginning; in practice, for example, it means our 404 pages can't show the correct theme. It would be nice if loaders were called in catch boundaries.

The problem is that the loader thrown the response that caused the CatchBoundary to render, that means you can't get the full response of the loader because your loader already run and thrown a response earlier.

What you can do is to add the theme or any other data you need to the body of the thrown response.

0 replies

kevinwolfcr · 2022-07-21T16:08:48Z

kevinwolfcr
Jul 21, 2022
Author

@sergiodxa how would you recommend me to pass down the domain name to the 404 page? Maybe doing something in entry.server.tsx?

0 replies

sergiodxa · 2022-07-21T16:33:04Z

sergiodxa
Jul 21, 2022
Maintainer

@elkevinwolf that would be a way, your entry.server could define a context provider with the domain name and then you can access it, and in entry.client you can do the same reading from window.location so both have access

Another way is to read the domain name and pass it as the data of the thrown response

export function loader({ request }: LoaderArgs) {
  let hostname = getHostname(request.url)
  throw json({ hostname }, 404)
}

With this, your CatchBoundary will have access to hostname in useCatch

0 replies

kevinwolfcr · 2022-07-21T18:42:16Z

kevinwolfcr
Jul 21, 2022
Author

@elkevinwolf that would be a way, your entry.server could define a context provider with the domain name and then you can access it, and in entry.client you can do the same reading from window.location so both have access

Another way is to read the domain name and pass it as the data of the thrown response
export function loader({ request }: LoaderArgs) {
  let hostname = getHostname(request.url)
  throw json({ hostname }, 404)
}
With this, your CatchBoundary will have access to hostname in useCatch

Good idea of wrapping with a context. Regarding the loader, we face the same problem, that it is not readable from the Root's Catch Boundary. The example you put, I assume is from a regular route, not the Root component. Actually, if I throw a 404 response from any route, I am still able to read the Root's loader from the Root's Catch Boundary.

0 replies

kevinwolfcr · 2022-07-31T05:13:57Z

kevinwolfcr
Jul 31, 2022
Author

Update: I managed to hack around this by adding a Splat Route throwing a 404 error status code.

app/routes/$.tsx

import { notFound } from "remix-utils"

export function loader() {
  throw notFound(null)
}

export default function NotFound() {
  return null
}

2 replies

andreiduca Mar 17, 2023

I ended up doing the exact workaround, but unfortunately this is just that: a workaround 🙃.

Can we say it's a safe assumption that the root loader provides globally available data (like the user being logged in, the theme being used, etc), regardless if the page visited exists or not?

In this case, yes, I would also expect the root loader (and the root loader only) to be accessible in the root error/catch boundary, since most likely it was NOT the root loader throwing the 404 in the first place.

andreiduca Mar 17, 2023

Fyi, I see this as a feature request rather than a bug, since the current behavior is by design.

machour · 2023-01-22T10:43:05Z

machour
Jan 22, 2023
Maintainer

Converting this to a discussion as I'm cleaning up the issues.

If this is a request for a new feature, please post a Proposal in the discussions tabs.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Root loader not being called in CatchBoundary #5186

{{title}}

Replies: 10 comments 2 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

Select a reply

Root loader not being called in CatchBoundary #5186

kevinwolfcr Jul 15, 2022

What version of Remix are you using?

Steps to Reproduce

Expected Behavior

Actual Behavior

Replies: 10 comments · 2 replies

kiliman Jul 16, 2022 Maintainer

revelt Jul 18, 2022

kiliman Jul 18, 2022 Maintainer

kevinwolfcr Jul 19, 2022 Author

sergiodxa Jul 20, 2022 Maintainer

kevinwolfcr Jul 21, 2022 Author

sergiodxa Jul 21, 2022 Maintainer

kevinwolfcr Jul 21, 2022 Author

kevinwolfcr Jul 31, 2022 Author

andreiduca Mar 17, 2023

andreiduca Mar 17, 2023

machour Jan 22, 2023 Maintainer

kevinwolfcr
Jul 15, 2022

Replies: 10 comments 2 replies

kiliman
Jul 16, 2022
Maintainer

revelt
Jul 18, 2022

kiliman
Jul 18, 2022
Maintainer

kevinwolfcr
Jul 19, 2022
Author

sergiodxa
Jul 20, 2022
Maintainer

kevinwolfcr
Jul 21, 2022
Author

sergiodxa
Jul 21, 2022
Maintainer

kevinwolfcr
Jul 21, 2022
Author

kevinwolfcr
Jul 31, 2022
Author

machour
Jan 22, 2023
Maintainer