Less Boilerplate, More Type Safety: React Navigation 8's Typed Hooks

If you've used React Navigation with TypeScript, the hooks may have felt lackluster. They didn’t have information on which navigator they were used in, so the types were broader and more generic.

This changes with React Navigation 8 (currently in alpha). The useRoute, useNavigation and useNavigationState hooks now have much richer types with runtime validation without needing the type-unsafe generic pattern of React Navigation 7.

In this article, we’ll dig deeper into the changes in these hooks and what they enable.

Typed hooks useRoute

Let’s say you have a Header component that you use in every screen in your app, but you want to change the style a bit on the Profile screen based on the userId param.

The useRoute hook is perfect for this, as it provides the route’s information including route.params for the screen containing our header:

const route = useRoute();

In React Navigation 7, this wasn’t seamless. The type of the returned route object would be a generic type, where route.params is just object type without any type information. So you needed to provide a generic to useRoute or use as, both of which are unsafe escape hatches just to keep TypeScript happy.

In React Navigation 8, the same code now returns a union of all routes in the project. So you have strong param types out of the box.

What’s nice about this is that you can just check what route.name is to narrow the type of route.params to the appropriate value. No type-casts needed:

const route = useRoute();

if (route.name === 'Profile') {
  // ✅ Has the `params` type for Profile screen
  console.log(route.params);
} else if (route.name === 'Settings') {
  // ✅ Has the `params` type for Settings screen
  console.log(route.params);
} else {
  // And so on
}

It gets even better when you know that the component is used in a specific screen. You can pass the name of the screen to the useRoute hook, and it will return proper types:

This isn’t just a fancier API for the regular useRoute() with route.name checks. It also validates at runtime that the hook is used inside the Profile screen, so types and runtime can’t drift.

// ✅ Validates we're in `Profile` screen
const route = useRoute('Profile');

// ✅ Has the `params` type for Profile screen
console.log(route.params);

‍Not only that, passing a name also enables useRoute to return the route object of any parent screen that matches the name, not just the immediate parent.

Previously, accessing a parent screen’s route params like this required manually setting up context, or manually passing through props multiple levels. This boilerplate isn’t needed anymore.

useNavigation

If you have used React Navigation before, you know the navigation object. The useNavigation hook gives us this object for a screen. You probably use it already in most of the screens and components in them.

const navigation = useNavigation();

Let’s say we have a drawer navigator at the root, which has a HomeTabs screen that has a tab navigator which contains a Latest screen.

When you use useNavigation in the Latest screen, it returns the navigation object for Latest at runtime. However, the types identify it as the navigation object for the screen at the root. So navigation.navigate would show autocompletions for screens in the drawer navigator at the root and not for screens in HomeTabs.

This is by design, as the hook can’t verify where it is used. All actions like navigate bubble up to the root navigator, so it’s still correct and type-safe. But it also means that methods like setOptions won’t know which navigator’s options they can update, addListener won’t know which navigator’s events it can listen to, etc., so they won’t have proper types. The only way was to pass a generic or use an as cast, both of which are unsafe.

It mostly still works the same way in React Navigation 8. But now, you can also pass the screen name to useNavigation, just like with useRoute:

This makes the navigation object’s type accurate, rich with navigator-specific actions (e.g. for the Latest screen, navigation.addListener will know it can listen to the tabPress event, navigation.setOptions will have a bottom tabs-specific options type etc.).

const navigation = useNavigation('Latest');

// ✅ Can listen to bottom tab-specific events without type errors
navigation.addListener('tabPress', () => {
  // ...
});

It’s also nested navigator aware. So the navigation object will also have methods such as openDrawer since it’s nested under a drawer navigator.

When you use the Static API, this all comes for free; the types are inferred automatically.

But the Dynamic API isn’t left behind. Previously, the way to get an accurate nested-navigator-aware type was to manually combine navigators with CompositeNavigationProp or CompositeScreenProps. But all of this boilerplate is no longer needed:

- type ProfileScreenNavigationProp = CompositeNavigationProp<
-   BottomTabNavigationProp<TabParamList, 'Profile'>,
-   CompositeNavigationProp<
-     StackNavigationProp<StackParamList, 'Account'>,
-     DrawerNavigationProp<DrawerParamList, 'Home'>
-   >
- >;

- type Props = {
-   navigation: ProfileScreenNavigationProp;
- };

- function ProfileScreen({ navigation }: Props) {
+ function ProfileScreen() {
+   const navigation = useNavigation('Profile');

    // ...
  }

useNavigationState

The useNavigationState is one you’d use rarely. It makes it possible to read the navigator’s state with a selector for granular updates for more advanced usage. For example, if a screen needs to know the name of the previous screen in the stack:

const previousRouteName = useNavigationState(
	(state) => state.index > 0 ? state.routes[state.index].name : null
);

In React Navigation 7, state will be the generic navigation state without navigator-specific properties.

It gets the same treatment as the other hooks in React Navigation 8: it now accepts the name of the screen as its argument, similar to useRoute and useNavigation. This makes the state type match the type of the navigator’s state.

In addition, just like useRoute, it can now get the state from a screen in a parent navigator as well.

How to enable typed hooks?

Typed hooks aren’t a different API, but an extension to the existing hooks. They don’t need a separate step to enable them. Just set up the types following the official docs and you’re done:

• Setting up types for Static API
• Setting up types for Dynamic API

The TypeScript guide has been overhauled, so make sure to give it another read even if you have types set up already.

Especially for the Dynamic API, you’ll now need to provide the navigator type of the nested navigator to NavigatorScreenParams instead of the param list:‍‍‍‍

  type MyTabParamList = {
-   Feed: NavigatorScreenParams<FeedStackParamList>;
+   Feed: NavigatorScreenParams<typeof FeedStack>;
    Profile: { userId: string };
    Settings: undefined;
  };

Wrapping up

On the surface, React Navigation’s typed hooks may seem like a small addition, but they add up. You get richer types and new capabilities while reducing the boilerplate.

Type-safety has always been a goal of React Navigation, and typed hooks bring us much closer to the vision. Whether you write code by hand or with LLMs, strong type-safety means more guardrails and fewer chances of mistakes. So I’m pretty excited about the improvements to types.

Give the React Navigation 8 alpha a try, and hopefully you’ll love these hooks as much as I do.