route.params is undefined, nicer if it was an empty Object {} by default

[Jarred-Sumner]

React Navigation v5's API is so much better! This is a tiny thing.

Current Behavior
When there are no params passed to navigator.navigate, route.params is undefined. Additionally, the type definition doesn't indicate that params can be undefined.

This means that the following code will raise an exception because params is not an Object:

const {showStart, onChange} = useRoute().params

This makes sense. There are no params, so params is never set.

Expected Behavior

From a developer experience perspective though, It'd be a little easier if it was an empty Object when undefined. That way, I can use destructuring without optional chaining.

How to reproduce

Navigate to a route but don't pass any params to it.

const {showStart, onChange} = useRoute().params

Your Environment

├─ @react-navigation/core@5.1.2
│  ├─ @react-navigation/routers@^5.0.1
├─ @react-navigation/native-stack@5.0.3
├─ @react-navigation/native@5.0.3
│  └─ @react-navigation/core@^5.1.2
├─ @react-navigation/routers@5.0.1
├─ @react-navigation/stack@5.0.3
├─ react-navigation-animated-switch@0.4.1
├─ react-navigation-shared-element@0.5.0

--

In terms of how to implement this...maybe it could be an Object.defineProperty getter on the route object returned by useRoute with enumerable set to false, so that it doesn't show up if you JSON.stringify it, but its at least accessible?

[Grohden]

I'm curious:

Additionally, the type definition doesn't indicate that params can be undefined.

You mean that every TS dev should deal with undefined even when they know that it will never be undefined?

I would rather use this from the guides:

type RootStackParamList = {
  Home: undefined;
  Profile: { userId: string };
  Feed: { sort: 'latest' | 'top' } | undefined;
};

And annotate the provided hooks properly (https://reactnavigation.org/docs/typescript#annotating-useroute)

If you type things correctly, you probably will not run into these kind of issues, alternatively you could use:

const { showStart, onChange } = useRoute().params ?? {}

[andreasmischke]

You mean that every TS dev should deal with undefined even when they know that it will never be undefined?

That's the current state and should not be the case.

If you type things correctly, you probably will not run into these kind of issues

Unfortunately that's not the case. By typing things correctly, you can define that all of your params are optional. But that should not lead to the params object itself being undefined. Even if it does (which might be okay) the TS annotations should tell you that params is something™️ | undefined.

To say things simple: The TS annotations currently do not match the real behaviour of the library.

[Grohden]

That's the current state and should not be the case.

I still don't get it, you don't need to deal with undefined with current state, as I said, if you type things correctly you will not get a undefined as a param unless you type it as undefined and/or use ''unsafe'' calls. (there's a fault at the library typings: you can call navigate(string) and ts will not complain even when the route is required to have params)

By typing things correctly, you can define that all of your params are optional. But that should not lead to the params object itself being undefined.

Params will not be undefined if you use the types properly:

type RoutesParamList = {
   Foo: Partial<{ foo: string }>
   Bar: Partial<{ bar: number }> | undefined
}

Foo will need to be called with at least an empty object (navigate('Foo', {})), undefined is not accepted here.
Bar will accept undefined (navigate('Bar', undefined))

To say things simple: The TS annotations currently do not match the real behavior of the library.

Yeah... you have a point about the behavior, there's always the chance that the lib will send a undefined because it can send it by default.
But by adding | undefined at the lib, everyone will need to deal with undefined even when they make sure every call to navigate is using 'safe' types/correct generics, and by adding | {} at the lib, everyone will need to deal with optional arguments always.

Letting you choose how you deal with your types moves the responsibility to you, you chose what you deal with.

Also if you use {} instead of undefined (not adding the types and strict type check), you gonna have to deal with undefined in the end:

• Using undefined you get an error accessing any prop in it.
• Using {} you get undefined accessing props, its easier to pass them down and see errors somewhere else.

For me the last option is bad.

[Shywim]

As said in the issue's description, the expected behavior is to have an empty object by default. There's no reason to have to deal with undefined on params and params (or equivalent) is never undefined in other libs like react-router or just in the browser's native Location api.

I don't see why having individual props undefined is worst since you will often have to check them individually, whereas there is no bad implication I know of to have an empty params object when there's no param. So let's just have one less redundant check to do by default.

[Grohden]

whereas there is no bad implication I know of to have an empty params object when there's no param

Here's one TS specific issue, here's the playground

But maybe this ts issue could be solved by the router receiving a default value... 🤔

const useRouterWithDefs = <R, T>(default: T) => {
   const router = useRouter<R>()

   return useMemo(() => ({
       ...router,
       params: router.params === undefined ? default : router.params
   }), [router])
}

Anyway, as I said, for me is not good, but it's not so bad either, I use types correctly and doesn't receive undefined at my routes, so it doesn't make much a difference for me if it does not force me to validate undefined and/or empty objects

[vinipachecov]

Excuse me @Grohden but I could not follow the guides: Why does the second parameter of the RouteProp has be inside params list?

In the types.d.ts it was meant to be the actual RouteName, wasn't it? Dunno but looks confusing to me,.

Why this should be invalid ?

type RootStackParamList = {
  vaccine: string
};

type RouteScreenProp = RouteProp<Partial<{
  vaccine: VaccineModel;
}>, 'Profile'>;

All I want to type is that a specific route param will have a vaccine prop. I don't want to name the route 'vaccine'. Did I miss something?

[andreasmischke]

@vinipachecov Your RootStackParamList should contain the parameters for all your routes:

type RootStackParamList = {
  Profile: {
    vaccine: string // Or VaccineModel? You have to decide on one
  }
};

type RouteScreenProp = RouteProp<RootStackParamList, 'Profile'>;

[Grohden]

@vinipachecov wut?
The proper usage should be:

type RootStackParamList = {
  // Your route is named 'Profile', it has this object as params:
  Profile: Partial<{
      vaccine: VaccineModel
  }>
};

// here you say to ts 'take the 'Profile' entry type from RootStackParamList and use it as a type for route
type RouteScreenProp = RouteProp<RootStackParamList, 'Profile'>;

Edit:
Which part of the guides are confusing?

[vinipachecov]

Thank you @Grohden and @andreasmischke! I wasn't understanding the purpose of using the name to refer to a prop inside the param list.

[martintreurnicht]

I've run into this issue too, it's definitely and issue with how types work with regards to navigation params, consider the following route param list:

type RootStackParamList = {
  Profile: {
    vaccine: string
  }
  Home: undefined
};

If I try and do the following:

navigation.navigation('Profile')

I would expect an error, because params can't be undefined

But in reality that will work fine, but the issue will manifest in Profile Route:

const { vaccine } = route.params // throws undefined error for route.params but typescript doesn't indicate that it could be undefined

But, will work for Home, because params type is undefined

Maybe this is a limitation to typescript's type system and how it's being used here, in the case where you don't want to specify navigation parameters. The easiest would be to have params just be an object always, and if no params is specified, it's an empty object. Either that or the type for route.params not be made optional, right now it creates the illusion that params can't be undefined, where in reality they can be

[satya164]

@martintreurnicht that seems like a bug. can you open a bug report about it?

[Grohden]

(there's a fault at the library typings: you can call navigate(string) and ts will not complain even when the route is required to have params)

@satya164 @martintreurnicht I think that this could fix the issue:

type RootStackParamList = {
    Profile: {
        vaccine: string
    }
    Home: undefined
};

export type PropsOfType<T, O> = ({
    [P in keyof T]: T[P] extends O ? P : never
})[keyof T];

type Nullables = PropsOfType<RootStackParamList, undefined>
type NonNullables = keyof Omit<RootStackParamList, Nullables>

interface NavigationInterface {
    navigate(route: Nullables): void
    navigate<key extends NonNullables>(
        route: key,
        args: RootStackParamList[key]
    ): void
}

declare const navigation: NavigationInterface

navigation.navigate('Home')
navigation.navigate('Home', undefined) // Nope, cant explicity pass undefined.
navigation.navigate('Profile') // Not a nullable route'

But TS is very bad at showing you error messages :/ the above code doesn't make clear to you that you should be 'using' the second function definition

[satya164]

@Grohden can you send a PR?

[Grohden]

@satya164 not right now.. probably next week I'll open