[Feature]: Parent loader data availability in child loader

[siric]

What is the new or updated feature that you are suggesting?

Currently, components are able to get data from parent loaders with useRouteLoaderData. Since this is a hook, it can not be called in a loader function and so there is no way to make child fetches dependent on parent fetches.

Proposed API:

const loader = ({ routeLoaderData }) => {
  const parentData = routeLoaderData('parentId')
  ...
}

Why should this feature be included?

Many cases for dependent fetches.

[anupriya17]

We're stick with this as well

[timdorr]

This is not likely to be implemented. A similar thing is answered in the Remix FAQ: https://remix.run/docs/en/v1/pages/faq#how-can-i-have-a-parent-route-loader-validate-the-user-and-protect-all-child-routes

Loaders are called in parallel, so they cannot block each other or provide each other data. In the specific case of needing an ID from a parent loader, you would get that via the URL params. E.g., /users/:userID/posts/:postID and params.userID

(Bring on the thumbs downs... 😞)

[danielhstahl]

What is the best way to handle passing access tokens then? I have a top-level "loader" that performs authentication and retrieves an access token. But the "children" loaders can't access the access token. My workaround is to use "useEffect" hooks in my children components but that robs me of all the niceties that the data loaders provide.

[machour]

You could store that access token in a cookie and access it from your other loaders by reading request.headers

[moronifacundo]

https://jankraus.net/2022/04/16/access-remix-route-data-in-other-routes/

This was useful for me and I guess it will be useful to some people that get here

[qwertie]

@machour No, because the other loaders run before the access token has been retrieved by the parent loader. The fact that parents are not initialized before children is a much bigger issue than where to store info (cookies etc). The location only matters after one has dealt with ordering.

Remix FAQ says "This is probably not different than what you were doing before Remix, it might just be more obvious now". No, wrong, it's much different. Previously, when our app didn't have URL-based routing,

1. the user had to wait for the basic UI to load before navigating to a child page, so the child page could rely on a authentication, authorization, and loading of "outer" data to have already been done.
2. the UI used React Suspense, which you can set up so that parent stuff is loaded before child stuff begins to load.

I am baffled that this is considered unimportant in react-router... so unimportant that the documentation doesn't even mention this surprising behavior. (It's also strange that unstable_useBlocker is still unstable two years after react-router v6 is released, and that <Route loader={...}> silently fails to work outside the context of createBrowserRouter(createRoutesFromElements(...)) even though createRoutesFromElements was only meant as a temporary construct for upgrading v5 apps which didn't use loader 🤷‍♂️. And now I learn that react-router is based on "remix", but what is remix? Well if I visit the docs and click "If you're wondering what Remix is, this is the page for you" I get an error page. Luckily I can reach the same page by clicking "Technical Explanation" on the sidebar, and it tells me that Remix is "1. A compiler 2. A server-side HTTP handler 3. A server framework 4. A browser framework" and I'm thinking "Holy Moly I just wanted client-side routing, what in tarnation is all this?!</Rant> My guess: Remix is essentially react-router without the "react" part)

[janzelenka-ext54467]

this is really a huge problem. I end up with only skeletal root component (just one div + outlet), and everything in leaf routes and components. Loaders are just in leaf routes.

Only other alternative I can think up was give up on loaders and use useEffect()

[Chrissmith1991]

Could you use react query and just pass the query client into the route loader and then fetch the data from the query cache?

[einarq]

I worked around it by putting the router inside another component that I render via React.lazy.

We call a signIn method in the bootstrapping phase, prior to rendering the main React app tho, which is probably not what others are doing. We don't use a a loader to get config and token.

More or less like this:

const LazyApp = lazy(() => import('./AppContainer'));

(async () => {
      await SsoManager().signIn();

      const root = createRoot(document.querySelector('.application-wrapper')!);
        root.render(
          <Suspense fallback={<ApplicationLoader />}>
            <LazyApp />
          </Suspense>
        );
})();

[steinybot]

@timdorr this is not true:

Loaders are called in parallel, so they cannot block each other or provide each other data.

Well first of all they aren't called in parallel, they are started asynchronously which is entirely different but that's not my main gripe. Assuming that's what you meant, of course they can still block each other, that's exactly what then does. All you need to do is make sure that you start the loaders in right order. See #11319 for a proof of concept.