--- title: "Less Boilerplate, More Type Safety: React Navigation 8's Typed Hooks" description: "React Navigation 8 improves typed hooks with screen-aware types, less boilerplate, and fewer unsafe casts in shared UI and nested navigators." url: https://www.callstack.com/blog/less-boilerplate-more-type-safety-react-navigation-8s-typed-hooks updated: 2026-10-25T20:07:25.079Z --- # Less Boilerplate, More Type Safety: React Navigation 8's Typed Hooks React Navigation 8 improves typed hooks with screen-aware types, less boilerplate, and fewer unsafe casts in shared UI and nested navigators. _By Satyajit Sahoo, Software Engineer @ Callstack · Published 2026-06-29 · Category: React Native_ 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`](https://reactnavigation.org/docs/8.x/use-route) hook is perfect for this, as it provides the route’s information including `route.params` for the screen containing our header: ```javascript 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. Your browser does not support the video tag. 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. Your browser does not support the video tag. 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: ```javascript 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: Your browser does not support the video tag. 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.** ```javascript // ✅ 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`](https://reactnavigation.org/docs/8.x/use-navigation) hook gives us this object for a screen. You probably use it already in most of the screens and components in them. ```javascript 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. Your browser does not support the video tag. 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`: Your browser does not support the video tag. 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.). ```javascript 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: ```diff - type ProfileScreenNavigationProp = CompositeNavigationProp< - BottomTabNavigationProp, - CompositeNavigationProp< - StackNavigationProp, - DrawerNavigationProp - > - >; - type Props = { - navigation: ProfileScreenNavigationProp; - }; - function ProfileScreen({ navigation }: Props) { + function ProfileScreen() { + const navigation = useNavigation('Profile'); // ... } ``` ### `useNavigationState` The [`useNavigationState`](https://reactnavigation.org/docs/8.x/use-navigation-state) 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: ```javascript 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. Your browser does not support the video tag. 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](https://reactnavigation.org/docs/8.x/typescript?config=static#setting-up-the-types) - [Setting up types for Dynamic API](https://reactnavigation.org/docs/8.x/typescript?config=dynamic#setting-up-the-types-dynamic) 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:`‍`‍`‍`‍ ```diff type MyTabParamList = { - Feed: NavigatorScreenParams; + Feed: NavigatorScreenParams; 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](https://reactnavigation.org/docs/8.x/getting-started) a try, and hopefully you’ll love these hooks as much as I do.