Loading data in ReactRouter v7 - useLoaderData vs loaderData prop

[ondrejsevcik]

Hi, since upgrading to ReactRouter v7, I'm struggling to understand what's the preferred API to load data.

Previously, we've used useLoaderData<typeof loader>() hook. Now I see in some places in the documentation that the default route component accepts also loaderData property.

1. What's the difference between those two APIs? And which one is preferred and why?
2. How do you test the Component when using loaderData as a prop (the createRoutesStub does not accept component that defines loaderData)?

export default function SomePage({ loaderData } : Route.ComponentProps) {
  const { serverData } = loaderData;
  const { serverData } = useLoaderData<typeof loader>();
  // .. what's the difference between the two above? 
}

Thank you

[gustavopch]

AFAIK, the prop is preferred, but the hook is available so you can easily access the data deep in the component tree. Particularly, I think it's better to explicitly pass what you need to child components so they aren't coupled to the route.

[ondrejsevcik]

Do you know how to test the components that use the loaderData prop? The createRoutesStub does not accept such components unfortunately.

[OscarAyoy]

I had some success by simply wrapping my component in a function:

const Stub = createRoutesStub([
  {
    path: "/",
    Component: () => (
      <Home
        loaderData={{ user: { name: "Jack Klompus", role: "President" } }}
      />
    ),
  },
]);

That seemed to work as expected, but since Route.ComponentProps also requires both params and matches properties, TypeScript was left wanting more. params can simply be set to the empty object ({}), but creating a dummy matches value proved difficult enough for me to wonder if this really was the right way to go about it.

[gothedistance]

I felt exactly the same pain.

When using Route.ComponentProps, you’re required to provide all the props — loaderData, actionData, params, and matches — which makes the createRoutesStub code look like this (it doesn’t even compile, just for illustration). Disgusting.

const Stub = createRoutesStub([
    {
      path: "/",
      Component: () => (
        <HomeComponent
          loaderData={{
            categories: [
              { label: "test", value: 1 },
              { label: "test2", value: 2 },
            ],
            searchResult: {
              items: [],
              total: 1,
            },
          }},
          actionData={{
            error: "error"
          }},
          params={{}}
          matches={[
            {
              id: "root",
              params: {},
              pathname: "/",
              data: undefined,
              handle: undefined,
            },
          ]}
        />
      ),
    },

It’s far simpler and more understandable to just mock the loader and action, and pass them to the route — at least when it comes to writing tests.

In the end, I removed all usages of Route.ComponentProps and rewrote everything useLoaderData<typeof loader> and useActionData<typeof action>.

If there are any advantages to exposing props with Route.ComponentProps, I’d really love to hear them.

[DBulinski]

Same on our side. It would be much appreciated to make Component to just pass loaderProps generated from whatever loader returns. It is also much more flexible solution IMO, as one can use mocked loader and someone else can run actual loader code. Exactly as it was designed in Remix I think