With React Navigation 7, how do you open NotificationSettings, a screen in the Profile tab's nested settings stack, from the Discover tab?

## The navigation tree in a dating app Consider a dating app built with **React Navigation 7**: - a root **stack** with `MainTabs`, a full-screen `Chat` and a `Paywall` modal; - `MainTabs` is a **bottom tab navigator** with `Discover`, `Matches` and `Profile`; - `Profile` renders a **nested stack**: `ProfileHome`, `Settings`, `NotificationSettings`. Each navigator owns its own routes and state. The tab navigator knows the name `Profile` but not `NotificationSettings`; only the nested stack knows that name. ## Addressing a nested screen To reach a screen inside a nested navigator, you navigate to the **screen that renders that navigator** and describe the child in the params: ```tsx navigation.navigate('Profile', { screen: 'NotificationSettings', params: { section: 'matches' }, }); ``` The nested params object accepts these keys in the pinned types: | Key | Meaning | |---|---| | `screen` | the child screen to open | | `params` | that child's own params | | `initial` | `false` keeps the nested navigator's initial route underneath | | `merge` | merge the child's params into its existing params | | `pop` | go back to an existing child route instead of pushing | | `state` | a full nested state, used instead of `screen` | For a deeper tree the shape repeats: from the root stack you would write `navigate('MainTabs', { screen: 'Profile', params: { screen: 'NotificationSettings' } })`. ## Why the short form fails in v7 A navigation action is first offered to the navigator of the screen that dispatched it. If that navigator has no route with the name, the action **bubbles up** to the parent, then the grandparent, up to the root. In React Navigation 7 it is **not** passed **down** into child navigators by default. So `navigate('NotificationSettings')` from `Discover`: 1. the tab navigator has no screen with that name; 2. the root stack has none either; 3. nobody handles it, and in development the container logs that the action was not handled by any navigator, with a pointer to the nested-navigation docs. The container prop `navigationInChildEnabled` restores the older behaviour of trying child navigators, but it is marked deprecated, only works when the child navigator is already mounted, and is slated for removal in the next major release. The explicit nested form is the supported API. ## The initial route problem What happens next depends on whether the nested stack has been rendered: - **Already rendered** (the user visited Profile before): the stack receives a `navigate` to `NotificationSettings` and pushes it on top of what it has. - **Not rendered yet** (tabs mount lazily on first visit): the stack is **initialised with only the target screen**. `NotificationSettings` appears, but there is no `ProfileHome` beneath it, so the back button in that stack has nowhere to go. Passing **`initial: false`** changes the second case: the stack first initialises normally from its `initialRouteName`, then navigates to the target, so `ProfileHome` sits below `NotificationSettings` and back works as users expect. ## Params, merge and pop in nested navigation Params for the child go in the inner `params`, never at the outer level: `navigate('Profile', { section: 'matches' })` would give the section to the `Profile` route of the tab navigator, where the settings screen never sees it. `merge` and `pop` behave as they do on a flat `navigate`: `merge: true` keeps the child's existing params, and `pop: true` returns to an existing `NotificationSettings` in the nested stack rather than pushing another. ## Practical guidance - Use the nested form everywhere in feature code; do not rely on deprecated child navigation. - Add `initial: false` whenever the target is not the nested navigator's first screen and back should lead into that navigator. - Do not give a nested screen the same name as the screen that hosts its navigator, such as a `Profile` tab whose stack starts with a screen also called `Profile`. React Navigation warns in development that it found screens with the same name nested inside one another, because a navigation to that name becomes ambiguous. - Remember v7's stack semantics apply inside the nested stack: if `NotificationSettings` is already open there, a second nested `navigate` pushes another copy unless you pass `pop: true` or configure `getId`. - With TypeScript, declare the tab's param as `NavigatorScreenParams<ProfileStackParamList>`, so the compiler checks the `screen` name and its params.