Replies: 8 comments 1 reply
-
The throw new Response(JSON.stringify({ tenant: "Tenant1" }), {
status: 404,
}); and in your export function CatchBoundary() {
let caught = useCatch();
let data = JSON.parse(caught.data);
// data = { tenant: "Tenant1" } |
Beta Was this translation helpful? Give feedback.
-
Also, if you can determine the tenant from the request, you can add the tenant information to the Note: the |
Beta Was this translation helpful? Give feedback.
-
Yes but when remix doesn't find any matching route from the URL of the initial document, it leads us to the root's CatchBoundary without any contextual data. This case is not something WE throw, and the thrown response's data is null. It's complicated to display the right language, or the right styles if it depends on the hostname, for example. |
Beta Was this translation helpful? Give feedback.
-
@manzano78 You're right. If you don't control the thrown Response, then the CatchBoundary doesn't have any context. I patched Remix to include the "Request" object (actually a subset, since it has to be serializable) as well as the load context. Is this what you're looking for? // server/index.js
const getLoadContext = (req, res) => ({ tenant: "Tenant1" });
// root.tsx
export function CatchBoundary() {
const caught = useCatch();
return (
<Document title={`${caught.status} ${caught.statusText}`}>
<Layout>
<h1>
{caught.status}: {caught.statusText}
</h1>
<pre>{JSON.stringify(caught, null, 2)}</pre>
</Layout>
</Document>
);
} |
Beta Was this translation helpful? Give feedback.
-
@kiliman that's excellent! I imagined something else: the possibility to export a new optional specific 404 loader in entry.server.tsx. It would have the request and the context as arguments and would expect in return something that will be serialized (to become the caught.data in root's CatchBoundary). What do you think about that? |
Beta Was this translation helpful? Give feedback.
-
Not sure. That would be up to the Remix team. My patch only adds a few lines of code. Here's the patch if you're interested. https://gist.github.com/kiliman/c1e1dc34324a500f0cffd1fef4d87ad4 |
Beta Was this translation helpful? Give feedback.
-
@kiliman Looks nice and simple to me too. Why don't you create a PR so it can get some more feedback? |
Beta Was this translation helpful? Give feedback.
-
+1 for some sort of loader for root catch/error boundaries |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
What is the new or updated feature that you are suggesting?
Some method to supply context to CatchBoundary by adding a prop / loader / global request context.
Some ideas:
Simplest method I can think of, also has the benefit of always working even if an exception is thrown somewhere.
Not sure how this would work, unless there was a separate loader for 404 errors. (in the first place it's a bit strange to me that a 404 is handled by CatchBoundary, because the loader is not executed in the first place)
Would be nice if there was some way to add a global
requestContext
that's used everywhere, instead of inside every loader. This would also allow for a single implementation across routes and boundaries (and maybe other future features)Why should this feature be included?
When creating a CatchBoundary to catch 404 errors, it seems there is no way to get any context. When implementing a multi tenant system, this makes it impossible to show the correct error page (since it's not possible to get the host, I won't know what the current tenant is).
Beta Was this translation helpful? Give feedback.
All reactions