Root loader data not available in the root ErrorBoundary

[meglio]

Any reason why root loader data is not available in the root ErrorBoundary?

I need global application data, that I usually supply through the root loader, to be available in both normal application rendering and in the root ErrorBoundary. For instance, if the path has not been found, the root loader still makes sense, doesn't it? But for some reason it is null.

[meglio]

The way it works now is: I read some data from a local config file, and return it as the root loader data. However, if a 404 Not Found error happens, I can't access that root loader data. For instance, I need to to read the application name - literally the name that is used in <title> and is written at the top of the layout.

[sergiodxa]

Because the reason why the root error boundary was rendered could be that the root loader failed, in that case there’s no root loader data.

You can use useRouteLoaderData to access it and handle the case when it’s undefined https://sergiodxa.com/tutorials/access-remix-s-loader-data-from-a-root-errorboundary

[meglio]

I think the documentation is also a bit self-delusional in that it is not always the case when the loader failure is what led to ErrorBoundary. The "assumption" behind making loader data unavailable is wrong in the first place: it could have just returned "undefined" if the loader has failed, or the actual loader data if it has not. Do you see any reasonable explanation why useLoaderData() can't make that check but useRouteLoaderData() can?

[meglio]

If it returns undefined it means the loader failed, are you throwing a response?

My root loader:

export function loader() {
    let data = get_global_application_data_from_config();
    return data;
}

This basically loads data from config.ini. If it does not fail on an existing route, I don't expect it to fail on a non-existent 404 route. Is my logic flawed?

[meglio]

Is root loader called for non-existent routes?

[kiliman]

It's not really "making a check". Those hooks simply return the values stored in Remix context.

Remix assumes that if you call useLoaderData then everything is on the happy path and that you should always have a valid value.

With useRouteLoaderData, you can call it for any route id, even non-existent ones, so it is possible it will return undefined, since that route data won't be in the context.

Remix isn't being lazy here. It's very possible that for a given route that has, let's say 3 loaders, that all but 2 of them are successful, but the third throws an error. This will force Remix to render the nearest ErrorBoundary. At this point, it doesn't really know what loaders were successful or not. That's why it says, don't call useLoaderData since that assumes the happy path. But useRouteLoaderData will return whatever loaders were successful, and it's your responsibility to check which ones.

If you try to access a non-existent route, Remix will throw a Not Found response, so it's possible that none of your loaders are called. So your loader didn't even get a chance to fail. Again, Remix can't guarantee the state of your loaders once you are in the ErrorBoundary.

Anyway, given that, my example will show how you can setup some app global data that doesn't depend on the root loader. I'm almost finished with it.

[meglio]

Remix isn't being lazy here. It's very possible that for a given route that has, let's say 3 loaders, that all but 2 of them are successful, but the third throws an error. This will force Remix to render the nearest ErrorBoundary. At this point, it doesn't really know what loaders were successful or not. That's why it says, don't call useLoaderData since that assumes the happy path. But useRouteLoaderData will return whatever loaders were successful, and it's your responsibility to check which ones.

If you try to access a non-existent route, Remix will throw a Not Found response, so it's possible that none of your loaders are called. So your loader didn't even get a chance to fail. Again, Remix can't guarantee the state of your loaders once you are in the ErrorBoundary.

Many thanks, these two are very thorough explanations, I'd put them into the Remix documentation as they clarify a lot of things.

[kiliman]

I've got a solution that lets you set global app data that can be used in any route, as well as the error boundary.

Request-specific data (like host header) will need to be returned from loaders, though. However, I also have a solution for returning request data to your error boundary as well.

I'll be posting an example repo later today. My example uses Vite, but I imagine it will work on the classic compiler.

[meglio]

Could you please post a link to that example here as well. Many thanks.
P.S. I use the latest Remix and in the Vite mode.

[meglio]

Note: I can see define in Vite, but it does not solve the problem because:

Entries will be defined as globals during dev and statically replaced during build.

I need it to pick up the data from the file when the server starts, and not hardcode it at the build stage.

[kiliman]

I replied to another of your issues with more detail. I will be posting the final example to GitHub.

[meglio]

I was also thinking about the layout export, e.g. to load the data from the file in there and expose it as a global context. But it is rendered on both server side and client side, so doesn't look like a solution either.

[meglio]

Can't we just augment the html returned by Layout with some data? like e.g. a <script> that sets a global variable. I suspect there will be cases when the Layout is, again, called on the client side, thus not being able to read from a file.

In general, I feel frustrated that a simple task of exposing some server-side data to the client side takes so much effort and thought. This is not normal, and it feels like Remix is standing in my way rather than helping me to do the job.

[kiliman]

I finally got my example finished and deployed. Check it out here.

https://github.com/kiliman/remix-global-data

There's even a link to a deployed app.

[meglio]

This is quite detailed, thanks @kiliman .

1. Should it work without typescript type declarations?
2. Another concern of mines is that it looks like I'll need to introduceentry.server.tsx? So what happens if it changes - will we now have to constantly watch for the changes in that entry with every release, and notice the change, and somehow update it when it gets changed?

This looks like a workaround that is not proper and is asking for problems in the future. It could have beeen a "global app data API" provided by Remix. Something in line with: we just export getGlobalAppData in root.tsx and that is it. Will you consider adding such an API?

[meglio]

One more thing. Tried it in meta() with the intention to vary the favicon depending on the app globals, and it did not work. So then I moved <AppGlobalsScript /> into <head> and put it just before <Meta /> and <Links />, and it worked. Might be something to account for in your demo?

[kiliman]

True. I guess I don't see anything wrong with adding it to <head>. Good catch.

[kiliman]

This looks like a workaround that is not proper and is asking for problems in the future. It could have beeen a "global app data API" provided by Remix. Something in line with: we just export getGlobalAppData in root.tsx and that is it. Will you consider adding such an API?

I can only give you a solution/workaround that would help you solve your problem today. If you think that is not "proper", there's not much I can do for you then. You can certainly wait for an official API, but you may be waiting for a long time.

Just because you're using a framework doesn't mean you're not responsible for your own code. Sometimes, you'll have to write code that bridges the borders between your app and the framework. You can't expect a framework to support every use case. Luckily, Remix provides enough seams to let you add the necessary integration.

Personally, I don't have problems even using patch-package if it means getting my app to work the way I want it to.