Possible useParams TypeScript broken definition

[DragosMocrii]

import { useParams } from "react-router-dom"

interface JobPageRouteParams {
    jobId: string
}

const MyComponent = () => {
const { jobId } = useParams<JobPageRouteParams>();
}

gives an error: Type 'JobPageRouteParams' does not satisfy the constraint 'string'. .

The definition on useParams is

export declare function useParams<Key extends string = string>(): Readonly<Params<Key>>;

which means that the generic type is supposed to be a string?? Am I missing something here?

[DragosMocrii]

I looked more into the implementation of useParams, and I can't understand the decision for the current types. Wouldn't the following be more appropriate:

type RouteParams<T> = {
    readonly [key in keyof T]: string | undefined;
};

export function useParams<T extends Record<string, string>>(): Readonly<RouteParams<T>> {
  let { matches } = React.useContext(RouteContext);
  let routeMatch = matches[matches.length - 1];
  return ( routeMatch ? (routeMatch.params) : {} ) as RouteParams<T>;
}

Now, I could use it like this:

type JobPageRouteParams = {
    jobId: string
};

const { jobId } = useParams<JobPageRouteParams>();

[Grapedge]

Yes, but we can now use it like this:

const { code, tab } = useParams<'code' | 'tab'>()
// notice: `code`, `tab` may be string or undefined

[DragosMocrii]

Thank you, I was using old tutorials for v5 where the definition was different, and got tunnel vision. I see I can use string literals now.

On another note: v6 now returns the value of a param as string | undefined. What is the correct approach to using the value of a param? Doing a null check seems counterproductive and does not align well with function components. Using the non-null assertion operator seems kinda hacky. Am I missing the better approach?

[arendvosmaer]

On another note: v6 now returns the value of a param as string | undefined. What is the correct approach to using the value of a param? Doing a null check seems counterproductive and does not align well with function components. Using the non-null assertion operator seems kinda hacky. Am I missing the better approach?

I'm also curious about this: the behavior used to be that an undefined param would give you a 404, which I think makes sense, as the route doesn't match.

[benneq]

Those undefined params are bugging me.

I understand that in theory you could access some param key that's not within the route:

<Route path=":foo" />

const { bar } = useParams();
// bar === undefined

If you write code like this, then a check for bar !== undefined won't fix your code, instead it will just make it compile without errors and this will hide the underlying problem.

Though I'd vote to remove the undefined.

---

As an alternative you could leave the choice to the user which behavior he prefers, with something like this:

function useParams<K extends string, V extends string | undefined = string | undefined>(): {[key in K]: V} {
    // ...
}

const p1 = useParams(); // = {[key: string]: string | undefined}
const p2 = useParams<"foo" | "bar">(); // = {foo: string | undefined, bar: string | undefined}
const p3 = useParams<"foo" | "bar", string>(); // = {foo: string, bar: string}

[DragosMocrii]

I ended up using the non-null assertion operator when I want to tell TypeScript to shut up. So

<Route path=":foo" />

const { bar } = useParams<"bar">();
const fetchBar = useBar(bar!)

[chaance]

The rationale here for us, as I see it (and I've talked to Michael about it a bunch and believe he's of the same mind):

• Current type signature is simpler to type and output of string | undefined for values is technically correct
• If you don't like it, you have options:
  • Cast the return value: let { slug } = useParams() as { slug: string }
  • Use the non-null assertion operator, as @DragosMocrii points out (simplest IMO, no idea why this seems hacky to some, it's a language feature for a reason!)
  • Declare your own module and use whatever type signature you'd like: https://codesandbox.io/s/modest-lalande-bw2pf?file=/src/App.tsx
  • Use patch-package and override our types in a postinstall hook
  • Turn off strict null checks

[ppbl]

When I need to declare the type of the value, the current way cannot be achieved

Even if it must be a string, in ts, I can declare 'aa' |'bb' |'cc'

Before i can

There will be smart prompts when using params.type in this way

Not now, but this problem can be solved by function overloading

export function useParams<Key extends string = string>(): Readonly<Params<Key>>
export function useParams<
    P extends Record<string, string | undefined> = {
      [key: string]: string | undefined
    }
  >(): Partial<P>

In the code

 export function useParams<
    ParamsOrKey extends string | Record<string, string | undefined> = string
  >(): [ParamsOrKey] extends [string]
    ? Readonly<Params<ParamsOrKey>>
    : Readonly<Partial<ParamsOrKey>>

The best of both worlds! If possible, I can submit a pr

(The returned P is processed by Partial, which is consistent with the current logic)

[ParamsOrKey] extends [string] is to avoid Distributive Conditional Types

[michaeljota]

Hi @chaance. I wanna talk about your points about the desition of using Partial.

You said: "Current type signature is simpler to type and output of string | undefined for values is technically correct".
Yes, it is technically correct, but technically doesn't mean fully. As this is right now, the only one that knows what is actually correct is the developer, and thus, the only one that should be able to describe this fully is the developer.

After that you mention:

If you don't like it, you have options:

• Use the non-null assertion operator, as @DragosMocrii points out (simplest IMO, no idea why this seems hacky to some, it's a language feature for a reason!)
• Declare your own module and use whatever type signature you'd like: https://codesandbox.io/s/modest-lalande-bw2pf?file=/src/App.tsx
• Turn off strict null checks

• The reason why the non-null assertion operator is a language feature is to allow JS to move to TS easily, by taking the risk. We don't have any risk here, if I know that my param needs to be set in order to be able to show the page, I don't need to use the non-null assertion operator, this is an anti-pattern in most cases, and its usage is not recommended unless really needed (again, not the case if I can describe the whole thing properly). eslint rule

• Enhancing code that should work out the box sounds overkill for this.

• Turning off strict null check is not an option. That's an architectural choice that should be internal to be taken.

I understand that you think this is the best to really express what this means. However, I think it would be better for everyone to document the cases where using a partial would make sense, and let the user decide what shape they want to use.

[alecglen]

2nd'ing @michaeljota's points - options 1 and 3 are both steps in the wrong direction as far as TS is concerned, and declaring your own module as a workaround seems very odd when the rationale is "it's simpler to type".

Also like @michaeljota said, in my use case string | undefined is objectively incorrect. There is no logical way to route to ItemDetailsPage with an undefined itemId.

Route: <Route path="/item-details/:itemId" element={<ItemDetailsPage />} />
Hook: const { itemId } = useParams<'itemId'>();.

[timdorr]

Also like @michaeljota said, in my use case string | undefined is objectively incorrect. There is no logical way to route to ItemDetailsPage with an undefined itemId.

But you don't know that at compile time. TypeScript isn't aware of how the History API or the internals of React Router work. It can't enforce that for you, even if you have it that way logically. For example, you could be unit testing your ItemDetailsPage component without wrapping it in a Route

The idiomatic way of doing this is to add type guards for params. That's obviously pretty verbose in most cases, so we provide the generic with the safest case of what we know can exist in params at compile time.

[alecglen]

But you don't know that at compile time. TypeScript isn't aware of how the History API or the internals of React Router work.

That makes sense for why react-router can't automatically specify it as required. But then why does react-router make the assumption it could be undefined at compile time? There's no right answer for every possible scenario, which is why I believe @DragosMocrii's original interface proposal makes the most sense. #8200 (comment)

If I'm unit testing the component, then I'm just mocking useParams. I'm not changing the type signatures in my production component just to support tests.

[johnnyoshika]

I didn't want to scatter my code with the non-null assertion operator, so I decided to go with this. Equally bad (or good 😉), but I only need this declaration once inside a component instead of everywhere where the variable is used:

const { id } = useParams() as { id: string };