React-native-screens: The navigation.navigate() method can't navigate to the desired screen

[enheit]

Structure of the router

  Screen #1
  Screen #2

  Screen #3
    BottomTabNavigator
      Tab #1
        NativeStackNavigator
          Screen #5 (default)
          Screen #4
      Tab #2
        NativeStackNavigator
          Screen #6

After using props.navigation.navigate(...) from the Screen #2 component I was expecting to open Screen #4 inside Tab #1.

// Called from Screen #2
props.navigation.navigate('Screen #3', {
  screen: 'Tab #1',
  params: {
    screen: 'Screen #4',
  },
});

The actual result:
1) App navigates to the Screen #4.
2) then, app navigates back to the Screen #5 (which is default)
3) App tries to navigate back to the Screen #4 (which was desired)
4) App navigates back to the Screen #5
5) After that, I manually try to navigate to the Screen #4, the Screen #4
is opening, but there is no back button in the header, and I able only navigate back by using swipe back gesture.

The package.json

"@react-native-community/masked-view": "0.1.6",
"@react-navigation/bottom-tabs": "^5.5.1",
"@react-navigation/native": "^5.5.0",
"@react-navigation/stack": "^5.4.1",
"react-native-screens": "^2.8.0",
"react-native": "https://github.com/expo/react-native/archive/sdk-37.0.1.tar.gz",
"react-native-gesture-handler": "~1.6.0",
"react-native-reanimated": "~1.7.0",
"react-native-safe-area-context": "0.7.3",
"react-native-screens": "^2.8.0",

Platform: iPhone X (Software version 13.5)

P.S. See the attachment below to see the issue. (video)

IMG_7572.zip

[Hirbod]

I had the same issue today. When your TabBar is "lazy" (which is default), then a direct navigate through that tab will mount the desired screen as the initial screen and break your navigation flow (which is intended in this case) @enheit

You can override this behaviour simply by passing the initial: false prop.

Try to do it like this:

// Called from Screen #2
props.navigation.navigate('Screen #3', {
  screen: 'Tab #1',
  initial: false,
  params: {
    screen: 'Screen #4',
  },
});

Some docs about that:
https://reactnavigation.org/docs/nesting-navigators/#rendering-initial-route-defined-in-the-navigator

In your case, you might also try it this way:

// Called from Screen #2
props.navigation.navigate('Screen #3', {
  screen: 'Tab #1',
  initial: false,
  params: {
    screen: 'Screen #4',
    initial: false,
  },
});

Not exactly sure how often you need to set initial when navigating that deep in the tree.

[enheit]

@Hirbod, unfortunately it didn't help me. The broken animation still exist.

[WoLewicki]

Is it issue of react-native-screens? Does it work like that with normal stack navigator?

[enheit]

@WoLewicki yes, it works with normal stack navigator.

__Update__
I meant, that stack navigator works correctly. Issue exist only in react-native-screens and iOS devices.

[WoLewicki]

Ok, so can you provide a repo/snack with minimal configuration needed to reproduce the issue?

[enheit]

@WoLewicki, okay, I will try

[enheit]

Hey, @WoLewicki, I was able to reproduce this issue in stand alone project. You can find it by using this reference.

I was trying to put the same package.json and yarn.lock files that I use on my project.

__UPDATE:__
I found work around instead of using navigate to use push method.

Instead of this

props.navigation.navigate('Screen #3', {
  screen: 'Tab #1',
  params: {
    screen: 'Screen #4',
  },
});

use this

props.navigation.push('Screen #3', { // push instead of navigate
  screen: 'Tab #1',
  params: {
    screen: 'Screen #4',
  },
});

Maybe it will help you to understand the root of the problem

__UPDATE 2:__

This workaround behaves differently from the first approach, because it keep old routes in the memory where props.navigation.navigate reset routes (As far I understand).

At least my application start to behave differently. Doesn't fix the issue.

[WoLewicki]

I changed the native-stacks to normal stacks and the transition looks kind of similar. First going to the Screen1 with the Tab navigator and then to the nested Screen5 in the second tab. If you don't want that animation, you can use stackAnimation: "none" in native-stack. Or maybe the issue is something else and I don't understand it? The issue title says that you can't navigate to the desired screen, but I can't see this problem anywhere. When navigating from Screen3 to Screen5, all seem to work correctly.

[enheit]

When navigating from Screen3 to Screen5, all seem to work correctly.

@WoLewicki Could you please provide some gif to visualize "...seems to work correctly"?

I've uploaded two gifs which show the issue.

On the first gif I use import { createNativeStackNavigator } from 'react-native-screens/native-stack';

On the second gif I use import { createStackNavigator } from '@react-navigation/stack';

Note, that on the first gif the Screen5 after navigating from the Sceen3 opens and closes several times and disappear. While on the second gif the navigation seems to work correctly. After navigating from the Screen3 to the Screen5 using @react-navigation/stack it correctly opens Screen5 without any moves back and forth.

Correct me if I'm wrong

[WoLewicki]

I cloned your project and now I see the issue. You are using Expo and it has old version of the native code of react-native-screens. If you used this code in a bare RN project, you would spot no issue. So the solution is either not to use Expo or wait for the release of Expo SDK38 which should be out soon. Does it solve your issue?

[enheit]

@WoLewicki, you can close the topic if issue doesn't exist on the latest version of the react-native-screens and will be automatically fixed after updating to the Expo SDK38.

P.S. Can I install the latest version of the react-native-screens despite the fact that expo doesn't include it in the SDK37 to fix the bug?

[WoLewicki]

When using Expo Client on your phone, you cannot change the native code of libraries used in it. They change at each release of SDK. To change the native code with Expo, you would have to eject: https://docs.expo.io/bare/customizing/

[enheit]

@WoLewicki, I've updated to the Expo SDK 38 and issue disappear.

Thank you a lot.