How to write the correct type for useLoaderData()? (Typescript)

[blatoo]

Hi all,

I am follow the official tutorial, but with typescript. I have problem with useLoaderData() from here: https://reactrouter.com/en/main/start/tutorial#loading-data

  const { contacts } = useLoaderData();

The error is at contacts, it says:
Property 'contacts' does not exist on type 'unknown'.

So, my question is how to use the useLoaderData() with typescript correctly?

[Vanilla2]

Just stumbled across the same problem, I temporarily found the next workaround.

const data = useLoaderData() as Question[];

Where I definitely know that my loader returns an array of type Questions (which is defined by me).

I don't really like this work-around, as it defeats the purpose of typescript and it might introduce bugs.

[clarencetinator7]

I have encountered a similar issue but for useActionData() and this workaround seems to work.

[NoamAnisfeld]

@Vanilla2 I don't see how generics support would be more typesafe than casting. As long as the type of the data itself is unknown at compile time, all what a generics signature can do is implicit casting.

Assuming the data returned by the loader function is going through some sort of validation at some point, what we actually need is a way to connect to the return type of the loader function.

Perhaps we can go the other way around, and export the expected data type from the same module which we export the component from. Then import it on the router module and force the loader function to comply to that type. I shall try that and post it as an answer if it turns out to be useful.

[fredericoo]

@NoamAnisfeld you’re absolutely right in the sense of generics and casting are the same, just disguised as one another. The main advantage of generics here is to filter the types applying serialisation, extracting the value from the promise etc. That’s exactly the sort of utilities I was going for when creating react-router-typesafe. Just sprinkling the same behaviour of remix onto react router.

[NoamAnisfeld]

Thanks @fredericoo, your library is an impressing work. However it's model requires the loader to be part of the component module, which might not always be desired.

[soullivaneuh]

it's model requires the loader to be part of the component module

@NoamAnisfeld Do you mean on the same file? On that case, why should it be required? You can always export your loader from your module then import it on a component to use it with typeof. Am I wrong? 🤔

[fredericoo]

I've solved it with a simplified version of Remix's SerializeFrom function:

import { LoaderFunction } from 'react-router-dom';

export type LoaderData<TLoaderFn extends LoaderFunction> = Awaited<ReturnType<TLoaderFn>> extends Response | infer D
	? D
	: never;

usage:

your loader:

export const loader = (async () => {
	if (FORBIDDEN) return redirect('/signin')
	return { ok: true };
}) satisfies LoaderFunction;

Inside your component:

const data = useLoaderData() as LoaderData<typeof loader>;

It will:
✅ Work with data regardless of errors or redirects thrown
✅ Infer your returned data from the loader, without you having to manually type it.

---

EDIT: Released a very thin layer library with everything-typesafe: check out react-router-typesafe

[fredericoo]

And… I made a library for this. Don’t bother creating your own patches if yu want a ready-made solution: https://github.com/fredericoo/react-router-typesafe

[soullivaneuh]

@fredericoo Your library looks nice, but why not proposing your implementation to the react-router package directly? 🤔

[soullivaneuh]

I got my answer here: #9792 (reply in thread)

May you please share the links of the PR you submitted? Thanks!

[EdwinChua]

Hi all,

I am follow the official tutorial, but with typescript. I have problem with useLoaderData() from here: https://reactrouter.com/en/main/start/tutorial#loading-data

  const { contacts } = useLoaderData();

The error is at contacts, it says: Property 'contacts' does not exist on type 'unknown'.

So, my question is how to use the useLoaderData() with typescript correctly?

Specific to this tutorial (and OP's question), this is what worked for me:

    const { contacts } = useLoaderData() as { contacts: [] } || { contacts: [] };

The code uses the destructuring syntax on an object that looks like this:

{ 
    contacts: [] 
}

So providing the exact type, and performing a "short-circuit evaluation" to handle null values will help resolve this.

Further explanations here:

• https://stackoverflow.com/questions/70976866/cannot-destructure-property-as-undefined

• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Logical_OR#short-circuit_evaluation

[petenilson]

For those giving a thumbs down please can you explain what you don't like about this solution. I found this discussion also looking for a solution to this problem when completing the tutorial in typescript and I don't have enough experience to know why it's a bad solution.

[MattyBalaam]

Can you not use the recommended useLoaderData<typeof loader>()

[fredericoo]

I downvoted it because the runtime or assertion is not good in this instance. useLoaderData already falls back to an empty object to not break destructuring or accessing properties. Defaulting to an empty list will make handling loading states harder for no reason, and looks very unreadable — at first I read your code like as { contacts: [] } | { contacts: [] } and thought it was a typo, but you simply were casting and setting a fallback via ||.

@MattyBalaam As of today you cannot do that. Remix has support for generics in loaders, but react-router doesn’t. I even tried to submit a PR to it but the types are very deep and intertwined, and it ended up being very challenging to do without breaking anything.

For my personal usage, I wrote react-router-typesafe but I think it also fixes most ppls issues. It has generics where you’d expect, defer and Await work as you’d expect, and I also made links have editor auto-completion.

[ryankshaw]

I remember in early Remix, you had to put those as everywhere you used useLoaderData, but then the remix team did some really cool fancy typescript work so that when you are in remix-land you can do

useLoaderData<typeof loader>()

But it looks like the version that they back-ported to react-router can't do that. That will give you: Expected 0 type arguments, but got 1

to get around it, you can do:

useLoaderData() as Awaited<ReturnType<typeof loader>>

But every time I put an as in my code I feel like I'm introducing future lies. @ryanflorence do you know if you plan on adding that typescript fancyness to the react-router version of useLoaderData? (as in, make useLoaderData<typeof loader>() work like it does in remix?)

[fredericoo]

I know they’re not big fans of this sort of inference, even more so in remix as there’s serialisation needs to cross the backend-frontend boundary. I think Remix v3 will tackle (and fix) most of this, but meanwhile I’ve made a library with minimal patching to ensure react-router works similarly to Remix: https://github.com/fredericoo/react-router-typesafe

[eric-horodyski]

@fredericoo - Is there a rationale behind creating a "fork" of react-router instead of contributing to a types package? Something like @types/react-router?

[fredericoo]

@fredericoo - Is there a rationale behind creating a "fork" of react-router instead of contributing to a types package? Something like @types/react-router?

react router is typed; Loader and action functions, json and defer however all return unknown or non inferred types. My library is a thin layer on top of these bringing generics passed as arguments and a bit more inference in the case of json and deferred. The aim is for it to behave closer to the way remix works.

The Remix team has actively said this is by design and they're still not happy with how remix implements it today. As it's a blocker for me in several projects, I've decided on publishing the library.

It's not typings on top of an untyped library, they're re-exports under different signatures to make developers' lives easier until we have a permanent, official solution. Try it out! I'm about to publish a patch to the Await component as well with the desired inference ◡̈

[eric-horodyski]

I see! Apologies for the misunderstanding, bouncing around different languages/frameworks/contexts doesn't always lend itself to asking the most accurate questions.

[LucasKuhn]

Carl Sagan, in his work The Demon-Haunted World: Science as a Candle in the Dark said: "There are naïve questions, tedious questions, ill-phrased questions, questions put after inadequate self-criticism. But every question is a cry to understand the world. There is no such thing as a dumb question".

Thank you both for the question and the answer, it made the current situation with react-router clear and the reasoning for the separate library 🙏

[rafaelbiten]

Until we have the generics for these fns, I decided to go with a helper fn that wraps the default useLoaderData:

function useDataFromLoader<LoaderFn extends LoaderFunction>(loaderFn: LoaderFn) {
  return useLoaderData() as Awaited<ReturnType<typeof loaderFn>>
}

Usage:

async function loader() {
  const data = await Promise.resolve({ foo: 'bar' })
  return data
}  satisfies LoaderFunction

function Component() {
  const { foo } = useDataFromLoader(loader)
  return <p>foo === 'bar': {foo === 'bar'}</p>
}

For the useRouteLoaderData, I used a similar approach:

export function useDataFromRouteLoader<LoaderFn extends LoaderFunction>(route: { id: string; loader: LoaderFn }) {
  return useRouteLoaderData(route.id) as Awaited<ReturnType<typeof route.loader>>
}

Usage:

const data = useDataFromRouteLoader(routeWithLoaderAndId)

I personally find this to be a simple solution to the problem, but I don't know if it's good enough to be part of the public API of the library, e.g.: have the useLoaderData take a loader fn just so it can figure out its return type...

[fredericoo]

bro this will ruin code splitting! your loader now is going to ship in the same chunk as your component code, which mostly isn't what you want.
Avoid importing the loader itself in your component if you want to code split your app. That's where typeof shines.

[mohsentaleb]

Awaited<ReturnType<typeof loaderFn>> can't always be the answer since loader isn't always with the signature (args: LoaderFunctionArgs) => unknown. It can sometimes be (curriedFunction) => (args: LoaderFunctionArgs) => unknown

Let me give you an example:
A common use case for a loader function is to fetch data from API which needs user's accessToken being available in the scope of that function. like so:

axios.get('/some/api/endpoint', {
    headers: {
        AUTHORIZATION: `Bearer ${authData.token}`
    }
})

After some digging and with the help of this stackoverflow question I came up with the following workaround:

// App.tsx
export default function App() {
    const { authData } = useAuth(); // A simple hook which helps us get access to some app Context.

    const apiClient = axios.create({
        baseURL: 'https://domain.com',
        headers: {
            AUTHORIZATION: `Bearer ${authData.token}`
        },
    });

    const router = createBrowserRouter(
        createRoutesFromElements(
            <Route path="content" element={<Component />} loader={contentLoader(apiClient)} />
        )
    );

    return <RouterProvider router={router} />;
}

And then in my Component:

// Content.tsx

// loader as a curried function
export const loader =
    (apiClient: AxiosInstance) =>
    async ({ params }: LoaderFunctionArgs) => {
        const contentInfo = await apiClient.get<Content>(
            `content/${params.id}`
        );

        return contentInfo;
    };

Now if we use Awaited<ReturnType<typeof loader>> we get the second curried function as the type which is async ({ params }: LoaderFunctionArgs) => { ...} and not the contentIndo.

[rafaelbiten]

I haven't tested this myself, but by looking at your code and that SO, the approach of wrapping useLoaderData into another function should still work, e.g.:

const apiClient = axios.create(...)
const loaderWithApi = loader(apiClient)

...

function Component() {
  // using the useDataFromLoader wrapper I suggested on my previous message
  // and typescript should be able to infer what contentInfo info is
  const contentInfo = useDataFromLoader(loaderWithApi)
  return <pre>{JSON.stringify(contentInfo, null, 2) }</pre>
}

You may have to refactor your code a bit for it to work. I'm still learning about the new router and looking for the pattern I like. So far, I have the basics set like so:

export const myRoute = {
  element: <Element />,
  errorElement: <ErrorElement />,
  loader: async function ({ params }) {
    if (!params.id) return { data: null }
    const data = await api.getSomethingWithId(params.id)
    return { data }
  } satisfies LoaderFunction,
}

// in the same file, no need to export
function Element() {
  const { id } = useParams()
  // using the useDataFromLoader wrapper I suggested on my previous message
  // Typescript should be able to infer that `data` is either `Something | null` (in this example)
  const { data } = useDataFromLoader(contactShowRoute.loader)
  ...

Then, when declaring the router:

const router = createBrowserRouter([
  {
    id: 'myPath', // id may be helpful in some cases: https://reactrouter.com/en/main/hooks/use-route-loader-data
    path: '/myPath',
    ...myRoute, // contains elements, loader, action...
    children: [ ... ] // keeping the children explicit
  }
])

It may be just a question of time before I find some drawbacks with this approach, but that's what I'm using so far and it works well with that little useLoaderData wrapper I wrote...

[seanmcquaid]

Does anyone have a solution for typing this when working with defer?? My current solution is to manually create an interface for the desired types when working with defer but would love it if we had a supported TS solution for using this hook from the maintainers if possible!

[fredericoo]

Hey! I. put together a library for all things react-router + typescript: https://github.com/fredericoo/react-router-typesafe

[ivosabev]

The lack of automated framework type safety between loaders/action and the route component is a big turn off at the moment. Could the core team address this asap?

[fredericoo]

I put this library together but cant wait for it to be deprecated: https://github.com/fredericoo/react-router-typesafe

[eric-horodyski]

Totally agree. I'm advocating the move to React Router 6 internally, but struggling because our framework is heavily geared towards TypeScript developers.

[mohsentaleb]

This would get even worse when you use defer in loader.
For a simple loader you could use const data = useLoaderData() as ReturnType<typeof loader>> but as soon as you use defer for your loader's return types are completely lost.

[fredericoo]

I’ve patched defer with my own type definition, maybe I’ll release a library for these react router typed methods, which work well for me!

[QuentinGibson]

@fredericoo how did you patch defer? I am struggling with it!

[fredericoo]

I ended up making a library, feel free to copy the source code or install it (I’ll maintain it as I’m using it in several projects)!

https://github.com/fredericoo/react-router-typesafe

[brandon-burciaga]

Bumping this as generic support seems pretty necessary here.

[fredericoo]

I tried writing a PR to improve generic support but it's VERY HARD. There are so many intertwined types I felt like I was breaking the whole thing.

[fredericoo]

Ended up making a library for these repeated uses: https://github.com/fredericoo/react-router-typesafe

[LucasKuhn]

Would love to see the oficial docs with a Typescript version of the tutorial

[ntkoopman]

Depending on what you think is acceptable, you could skip useLoaderData, and return a component from the loader itself:

const Users = ({users}) => {
  return (
    <div>
      {users.length} users
    </div>
  );
}

const loader = async () => {
  let users = await db.select.from(users);
  return <Users users={users} />
}

// You can reuse this component on every route
const Passthrough = () => useLoaderData() as JSX.Element;

const router = createBrowserRouter([
  {
    path: "/users",
    element: <Passthrough />,
    loader: loader,
  },
]);

[tar-aldev]

Imho it looks a bit weird that we don't have it in react-router-dom lib, given that remix has it.
https://remix.run/docs/en/main/start/tutorial#type-inference

The tutorials are quite similar, the unerlying routing is (probably?) quite simlar.
So not sure why we can't have the same consistent approach in both remix and react-router.

[kiliman]

Most likely because React Router doesn't have a network request between the loader and component. With Remix, the loader data is converted to a JSON payload, whereas with React Router, you return exactly what you get from useLoaderData.