Sub-navigator renders first screen in a stack

[skovhus]

Current Behavior

Current behavior: when opening a screen inside a sub stack navigator it always renders the first screen or the screen specified as initialRouteName. That makes sense for a top-level navigator, but it makes some things rather difficult for sub navigators.

Code example is here: https://snack.expo.io/H1Mgdt3MS

I have 3 screens:

• MainScreen
• ScreenA (modal)
• ScreenB (modal on the same level as ScreenA)

I don't want react-navigation to render any routes inside the modal stack unless I tell it to. Two reasons for this:

1. the screens inside the sub stack navigator requires params in order to work
2. I don't want a history entry in my app for the first screen (see the second gif below, where the back button should go to MainScreen)

Expected Behavior

There would be a way to bypass rendering the first screen in a child stack navigator. Setting initialRouteName to null would be logical to me.

How to reproduce

https://snack.expo.io/H1Mgdt3MS

Your Environment

software	version
react-navigation	3.11.1
react-native	0.59.10
node	node 10, 11 and 12
npm or yarn	yarn

[skovhus]

This issue started out as a conversation on Twitter.

Let me know if you have any workarounds for disabling this behavior.

[ericvicenti]

I have experimented with one solution for this problem.

The problem:

Say we have an app with nested stack navigators:

const Channel = ({navigation}) => {
  const channelId = navigation.getParam('id')
  return (
    <MyChannelScreen
      onNotifSettingsPress={() => {
        navigation.navigate('NotificationSettings', { channelId })
      }}
      channelId={channelId}
    />
  );
}

// All of the screens in this navigator need the "channelId" param. They also link to each-other
const ChannelSettings = StackNavigator({
  DisplaySettings,
  NotificationSettings,
  PrivacySettings
})

const App = StackNavigator({
  Home,
  Channel,
  ChannelSettings
})

How can NotificationSettings be opened directly, without opening DisplaySettings?

And, how can the channelId param be shared amongst all the DisplaySettings routes automatically?

A partial fix, with the current API:

Specify the exact route in the navigator that you want to go to:

    <MyChannelScreen
      onNotifSettingsPress={() => {
        navigation.navigate({
          routeName: 'ChannelSettings',
          action: NavigationActions.navigate({
            routeName: 'NotificationSettings',
            params: { channelId }
          })
      }}

A proposed solution:

Basically, we can start allowing params to be set on the navigator's route, and configure children routes to access these params.

const Channel = ({navigation}) => {
  const channelId = navigation.getParam('id')
  return (
    <MyChannelScreen
      onDisplaySettingsPress={() => {
        navigation.navigate('NotificationSettings', { channelId })
      }}
      onPrivacySettingsPress={() => {
        navigation.navigate('PrivacySettings', { channelId })
      }}
      channelId={channelId}
    />
  );
}

// All of the screens in this navigator need the "channelId" param. They also link to each-other
const ChannelSettings = StackNavigator({
  DisplaySettings: {
    screen: DisplaySettings,
    // Explicitly allow DisplaySettings to see the channelId set on the ChannelSettings route 
    inheritParams: ['channelId'],
  },
  NotificationSettings: {
    screen: NotificationSettings,
    inheritParams: ['channelId'],
  },
  PrivacySettings: {
    screen: PrivacySettings,
    inheritParams: ['channelId'],
  }
}, {
  params: {
    // Use this to configure the `channelId` as a param of ChannelSettings.
    channelId: null
  }
})

const App = StackNavigator({
  Home,
  Channel,
  ChannelSettings
}, {
  explicitParams: true, // Opt-in to this new param behavior (to avoid breaking changes in param behavior for other users)
})

[skovhus]

I didn’t know about the exact route workaround. I’ll try that.

inheritParams makes it possible to share params, but it doesn’t solve the issue of creating a route in the history, which wasn’t intentional. initialRouteName=null could do that.

[ericvicenti]

Changing the behavior on null would be a breaking API change, so I'd like to avoid it. We can discuss adding a new feature to help. For example, we could add a new option called homeRouteName, which would default to the same value of initialRouteName, but if you set it to null, it disables the "home route" behavior where that screen is always the first screen of the stack.

Also, note that inheritParams which is still just a proposal right now.

The current API (where I mentioned the "partial fix") allows you to navigate to the navigator route and specify the action, which should allow you to bypass the initial route.

[skovhus]

The current API (where I mentioned the "partial fix") allows you to navigate to the navigator route and specify the action, which should allow you to bypass the initial route.

The workaround works like a charm. 🙌

Being able to disable the “home screen” or “initial route” using a declarative API would be nice. I see that nullable initialRouteName would be a breaking change.

My point around your suggestion for inheritance of params was that it is a solution for a another related issue.

For now I’ll use the sub action workaround. Should we document this somewhere? Seems several people have issues with the initial/home screen in sub stack navigators.

[franj0]

I have same problem.
When I open tab in tab navigator i have new tab navigator with 2 tabs (A and B).

When I set initialRouteName: "B", I get tab A instead of B.

And this is problem only on iOS platform. On Android it works fine.

[Nicosan-K]

Hi, I'm having the same issue. I have a
BottomTabNavigator, which has two tabs.
Each tab has a StackNavigator:
Stack A: screens A-1 and A-2,
Stack B: screens B-1 and B-2.
No ‘initialRouteName’ prop is used.

Cases: how to navigate from screen B-2 to to screen A-2

Test 1: --> still Screen
this.props.navigation.navigate( {routeName: "A-2", params: { Id: id } } );

Test 2 (partial fix above):

this.props.navigation.navigate(
            NavigationActions.navigate({
                routeName: “A”,
                action: NavigationActions.navigate( {routeName: "A-2", params: { Id: id } } );
            }))

Test 3 (from TabRouter, similar to fix above):

this.props.navigation.navigate({
          routeName: ‘Tab’,
          action: NavigationActions.navigate({
            routeName: A,
            action: NavigationActions.navigate({
                routeName: "A-2",
                params: { Id: id }
            })
          })
      })

Result: In all three cases, Screen A-2 is displayed (a half a second) and then A-2 is loaded. Back navigates to A-1 (rather than B-2). Workaround mentioned above didn't work for me.

My current 'dirty' workaround:
I've imported a second instance of screen A-2 and named it screen B-3, which I've registered under stack B. It works, but is definitively not scalable.

@ericvicenti Any suggestions on why the workaround doesn’t work in my case?

[TeChn4K]

Any update on this behavior, in regard to the next v5 release ?
I have read somewhere that initialRouteName param could be dynamic. It could change this weird behavior?
Anyway, the partial fix works great, thanks a lot.

[satya164]

@TeChn4K it won't happen in v5

[github-actions]

Hello 👋, this issue has been open for more than 2 months with no activity on it. If the issue is still present in the latest version, please leave a comment within 7 days to keep it open, otherwise it will be closed automatically. If you found a solution on workaround for the issue, please comment here for others to find. If this issue is critical for you, please consider sending a pull request to fix the issue.

[Aure77]

Still a issue on v4. And v5 is not stable/released yet to be used in production... An app should be a big stack of screens where I can back to the previous screen.