Nested Navigators: Building Complex UI Flows

Why it exists

Modern apps require more than a simple list of screens. Users expect complex flows like a login screen leading to a tabbed interface, which itself can push new screens or open modals. Nesting is the fundamental mechanism in React Navigation for composing these different UI patterns together into a coherent application structure.

The mental model

Treat navigators as if they were regular React components. You can render a <Tab.Navigator /> inside a screen of a <Stack.Navigator /> just as you would render any other component. This creates a tree of navigators, where parent navigators contain and manage child navigators, each with its own set of screens.

How it works

When you nest navigators, each one maintains its own isolated state. This means each navigator has its own navigation history, its own screen options (like header titles), and its own route params. Actions like navigate() or goBack() are first attempted by the currently focused navigator. If that navigator cannot handle the action (e.g., goBack() on its very first screen), the action "bubbles up" to its parent navigator to be processed. This allows for localized control with a predictable fallback. Screens within a nested navigator can also access methods from parent navigators, like calling navigation.openDrawer() from a screen inside a stack that is itself inside a drawer.

When to use it

Use nesting for almost any non-trivial app. It is the standard pattern for combining different navigation styles. The most common use is a root stack navigator that handles authentication flows, with the main, authenticated part of the app being a separate tab or drawer navigator nested inside one of the stack's screens.

When not to use it

Avoid deep nesting without a clear architectural reason, as it can make the navigation state complex and hard to debug. If you find yourself passing params through many layers of navigators, consider using a global state manager (like React Context or Redux) to share data instead. Don't nest just to share code if a simple reusable component would suffice.

One canonical example

A common app structure involves a top-level stack navigator (RootStack) with screens for Login and Main. The Main screen's component is not a simple view but is another navigator, such as a BottomTabNavigator. This tab navigator then manages its own screens like Feed, Profile, and Messages. This isolates the authentication flow in the stack from the main app experience in the tabs. Pressing the back button on the Feed screen will not navigate to Login; it will be handled by the tab navigator's own history first.