React Navigation 7 Plans (WIP)

[satya164]

This is a discussion to keep track of things that we want to change in React Navigation 7. I plan it to be a much smaller release with very few breaking changes. It's still very far in future, but I'm creating this issue to keep track of the changes that I want to make.

Deprecate the bubbling to child navigators ✅

Due to backward compatibility reasons, React Navigation 5 and 6 support navigating to a screen in a child navigator with navigation.navigate(ScreenName) syntax. But this is problematic with the new architecture - it only works if the navigator is already mounted, doesn't work with TypeScript etc. That's why there's a special API to navigate to a nested screen (navigation.navigate(ParentScreenName, { screen: ScreenName })).

In React Navigation 7, I want to deprecate this behavior and disable it by default. For old projects which have such code, they will be able to add a prop on NavigationContainer to enable it.

Drop the ability to navigate with a key ✅

Currently, you can specify a route key to navigate to, e.g. navigation.navigate({ key: 'someuniquekey' }). But I feel that it's exposing implementation details and isn't ideal. None of the other actions support such usage either.

In addition, we have already added a better API (getId) which can be used for similar use cases - and gives users full control since they provide the ID and it's not autogenerated by the library.

So I want to drop navigating by a key entirely in favor of the getId prop.

Align onReady and navigationRef.isReady() ✅

Currently the onReady prop and navigationRef.isReady() work slightly differently. The onReady callback fires when NavigationContainer finishes mounting and we have also checked for deep links. The navigationRef.isReady() method additionally checks if there are any navigators rendered - which may not be true if the user is rendering their navigators conditionally inside a NavigationContainer that's not rendered conditionally.

We should either add the additional check to trigger onReady or separate it to a different method and prop.

Freeze navigation state object during development

Mutating the navigation state can cause various issues. But I have seen people doing this either accidentally or intentionally. So we'll freeze it during development to avoid this. It'll not be frozen in production to avoid the performance overhead of deep freezing on every change.

Make all screens after presentation: 'modal' as modal unless specified

Non-modal screens pushed after presentation: 'modal' have glitchy animation with regular stack, and get pushed below the modal in native-stack. There's no perfect solution, but automatically turning those screens into modals may make sense.

Disable transform and scale animations when reduceMotion is enabled

Currently we don't respect reduce motion. We should respect it and disable transform and scale animations. We also need to investigate how native navigation animations change and do the same for the animations trying to match native animations.

Remove the independent prop from NavigationContainer in favor of a component ✅

TODO

[zamotany]

Deprecate the bubbling to child navigators

Would would the new API do navigate to child navigators look like? Will users have to keep track if navigator is mounted?

[Titozzz]

I guess it will stay this way: (navigation.navigate(ParentScreenName, { screen: ScreenName }))

[tonyxiao]

We should either add the additional check to trigger onReady or separate it to a different method and prop.

@satya164 how would you work around this problem in react navigation 6?

[satya164]

It's only a problem if you're rendering NavigationContainer without any navigators. So if you don't want this problem then don't do that.

[kacperkapusciak]

Additional remarks:

Rename customAnimationOnGesture native-stack prop to animationMatchesGesture

customAnimationOnGesture makes you think this prop takes an object with an animation provided by the developer. In reality, it's just a boolean flag that animationMatchesGesture name reflects better.

Make nativeBackButtonDismissalEnabled native-stack prop to true by default

This change will make the Android back button rely only on JS rather than triggering navigation on the native side. Full discussion: software-mansion/react-native-screens#801

Split statusBarAnimation native-stack prop into two props

On iOS, statusBarAnimation decides on the animation of the appearance of the status bar on the screen. On the other hand, on Android, the same prop decides whether there is a transition between the colors of the status bar or not. The behavior between platforms is so different that it should be separated into two standalone props. On Android, this prop could be a boolean prop - statusBarColorAnimation.

Rename statusBarColor native-stack prop to statusBarBackgroundColor

To unify with react-native and expo status bars prop statusBarColor should be renamed to statusBarBackgroundColor.

[ajp8164]

Just a couple comments.

1. Navigating to nested navigators has overly complex syntax. If I want to nav from a screen on tab 1 to “deep” screen in tab 2 it gets messy. If all my screens names are unique the navigator should be able to figure it out for me.
2. I frequently use this lib with React Native Bottom Sheet. Closer coordination would be great.. I don’t use modals on this lib anymore.

[traviswimer]

For navigating to a deep screen, I think I would be a big improvement if you at least didn't have to use a massive object. In other words, if you could write something like this:

navigation.navigate(["FirstScreen", "SecondScreen", "ThirdScreen"], params);

instead of this:

navigation.navigate({
    name: "FirstScreen",
    params: {
        screen: "SecondScreen",
        params: {
            screen: "ThirdScreen",
            params
        },
    },
});

[fatlinesofcode]

you can useLinkTo for that, linkTo('/FirstScreen/SecondScreen/ThirdScreen?foo=bar')

for our project we created a modified version of the linkTo function, so we can use use a path and params object.

e.g.

const {push} = useLinkTo()
push('FirstScreen/SecondScreen/ThirdScreen', {foo:'bar'})

[okwasniewski]

TabView will have a significant API change released together with React Navigation v7, I've described the changes here: react-navigation/rfcs#88

[alexrequelme]

[satya164]

If you want a direct replacement for keys, the getId maybe what you're looking for - instead of key, you'd pass a param that matches the ID of the previous screen. But it really depends on the navigation structure.

[satya164]

It doesn't need to provide it since you'd be the one passing the param. You'd know what it is. You can even get it from the route object, or store your in a variable/state etc. and reuse it depending on what makes sense.

Besides, unless you really expect to add more screens with the same name in history before login flow is finished, which seems unlikely if you're prompting for login, then you can just go back by the name of the screen using popTo, no key or ID necessary.

[awojciak]

One question about "Deprecate the bubbling to child navigators": in v7 usage of nested navigators will be not recommended or will there be another way to navigate to a screen inside child navigator besides the legacy one?

[satya164]

What's being deprecated is navigating to a child screen with just the name - it's not even documented, you can still navigate using the documented API https://reactnavigation.org/docs/nesting-navigators#navigating-to-a-screen-in-a-nested-navigator

[awojciak]

Oh, I get it. Thanks a lot for a response.

[a-eid]

@satya164 any plans to support RTL in version 7 ?

[ansh]

What is the expected release date for v7? 2024 or 2025?

[cetfu]

👀