Type of matches (MetaMatches) is imprecise

[michaelboyles]

I'm using React Router as a...

framework

Reproduction

https://stackblitz.com/edit/github-yk2hokfb-9fz5u2rm?file=app%2Froutes%2Fproject.tsx

System Info

n/a

Used Package Manager

npm

Expected Behavior

Go to project.tsx which is inside a layout. Look at the type of matches (the ellipses are from Monaco, not from me, but hopefully you get the gist):

[{
    id: "root";
    params: {} & {
        [key: string]: string | undefined;
    };
    pathname: string;
    meta: MetaDescriptor[];
    data: undefined;
    handle?: unknown;
    error?: unknown;
}, {
    ...;
}, {
    ...;
}, ...({
    ...;
} | undefined)[]]

The actual array of matches at runtime is an array of length 3: (root, projects, project)

With this type, you can index at e.g. matches[10], even though there will never be that many matches.

Actual Behavior

That part at the end shouldn't be there.

...({
    ...;
} | undefined)

The problematic type is defined here:

https://github.com/remix-run/react-router/blame/20f51f45dbce89c09da807601ca2b19d2fef8373/packages/react-router/lib/types/route-module.ts#L54

It's hard to reverse engineer intent of how a type was written, so hopefully @pcattori can comment on this.

I believe the type should be this

type MetaMatches<T extends RouteInfo[]> = { [K in keyof T]: T[K] extends RouteInfo ? MetaMatch<T[K]> : never };

This is better for a few reasons. It allows correct bounds checking (the typechecker won't let you write matches[10] now, while you could before), and it removes that | undefined which as far as my tests found is never a valid value anyway.

[pcattori]

Technically, matches[10] for an array of length less than 10 does return undefined so the type isn't incorrect. But it certainly could be more precise.

[michaelboyles]

match[10] doesn't just resolve to undefined. It resolves to

{
    id: unknown;
    params: unknown;
    pathname: string;
    meta: MetaDescriptor[];
    data: unknown;
    handle?: unknown;
    error?: unknown;
} | undefined

So it's wrong in the sense that the first part is never actually an option.

This isn't just a theoretical issue. I was writing a generic function that searches the matches for a given ID and returns the match, and this junk on the end makes writing that function much harder (I found it impossible, but I won't rule out that there's a workaround)

[pcattori]

What I mean by "correct" is that the TS type checker does not produce any type errors. I agree that outside of the type system itself, its suboptimal. I already have plans to expose something like:

import type { Routes } from "react-router"

type Route = Routes["routes/my-route"] // keyed by route ID
//   ^? { params: { ... }, loaderData: { ... }, actionData: { ... } }

where params, loaderData, and actionData are the exact types for that particular route

We're also thinking about exposing that as a runtime hook like:

const route = useRoute("routes/my-route")
//    ^? { params: {...}, loaderData: {...}, actionData: {...} } | undefined

That way you can get type-safe access to other routes' data.

Again, this is still being designed/developed so its subject to change, but curious if that would help your use-case.

[michaelboyles]

This is the function I was trying to write

function findMatchById<T extends readonly { id: string }[], K extends T[number]['id']>(
    id: K, matches: T
): Extract<T[number], { id: K }> {
    const item = matches.find((i): i is Extract<T[number], { id: K }> => i.id === id)
    if (!item) {
        throw new Error(`No item found for id ${id}`)
    }
    return item
}

It works correctly with the type I provided at the top. The result is narrowed so you can type-safely access data from any match

const { /* type safe match data */ } = findMatchById("some id", matches).data;

With the current type, calling this with will always fail on the 2nd argument, because it won't accept the explicit undefineds. There's probably a way to rewrite it to fix that, but I'm showing it more as an example of how the current type is adding friction

I was planning to use this in a meta function so hooks would be out there

[pcattori]

@michaelboyles are you using React 19? Then you could drop meta export and specify the <meta /> tag in your component (which then lets you use hooks). That will likely be what our docs recommend soon

[michaelboyles]

Yup, I am. That's a good shout actually, thanks. I'll have a play with it. I'd seen that React feature but I hadn't twigged with what that meant for RR

I'd already pnpm patched the change I suggested, so I'm set for the time being anyway