Navigation outside the React lifecycle should be provided rather than docs with DIY solutions

[shamilovtim]

Current behavior

The React Navigation docs suggest creating a tiny abstraction layer for working with navigation from outside the React lifecycle. In v6 createNavigationContainerRef was provided which was a step in the right direction. I am suggesting to bring this whole code into React Navigation. Consider the following:

1. Seeing as how the ref might not be ready, this is probably a significant source of bugs, which creates extra tickets and triage. It would be much simpler to internally create the reference implementation for all applications and call it done.
2. The domain of the library is to handle navigation declaratively but implementing the outside React functionality necessitates the creation of navigational library business logic by the users of the library. This feels leaky and unnecessary.
3. Users are suggested to implement a queue in order to have their navigation handled but once again I go back to the point that the creation of complex abstractions for navigation is the domain of a navigational library and should not be the domain of the end user.

Would the authors of React Navigation consider adding a PR with this functionality or would they consider PRs from contributors?

Expected behavior

Provide navigation outside the React lifecycle without suggesting DIY implementations to end users

Reproduction

https://reactnavigation.org/docs/navigating-without-navigation-prop/

Platform

• Android
• iOS
• Web
• Windows
• MacOS

Packages

• @react-navigation/bottom-tabs
• @react-navigation/drawer
• @react-navigation/material-bottom-tabs
• @react-navigation/material-top-tabs
• @react-navigation/stack
• @react-navigation/native-stack

Environment

v6 latest

[satya164]

but implementing the outside React functionality necessitates the creation of navigational library business logic by the users of the library. This feels leaky and unnecessary

I don't really see what business logic needs to be created by users - you call createNavigationContainerRef and use the object returned like you'd with useNavigation. There is no need to check for isReady if you don't care about handling the case of what happens if you navigate before navigators are mounted. Since v6, it's a console.error which is supposed to let you know that something might be wrong in your code and not crash the app. The isReady method is exposed because you might want to handle it differently, not necessarily because you have to.

Users are suggested to implement a queue in order to have their navigation handled
creation of complex abstractions for navigation is the domain of a navigational library

That's not what's suggested, it's mentioned as one of the options because you could do this based on your requirements. I don't have such queue maintained in any app I have worked on and haven't needed it. I believe most apps don't need queue for navigation actions.

A queue makes sense for any event listeners you add, and that's something handled by createNavigationContainerRef already.

Seeing as how the ref might not be ready, this is probably a significant source of bugs, which creates extra tickets and triage

I don't disagree, but if your application code is trying to navigate before your app is mounted, then it's something you need to investigate and fix in your app logic. React Navigation could try to make it easier to debug such things if there's anything that could be done here.

The library can't decide what to do when you're navigating even before anything is mounted, because we don't know what your use case is and what makes sense for your needs. Most apps wouldn't need a queue and queuing can cause bugs if the data has changed since the action was queued.

The ref approach is really an escape hatch that shouldn't be used often anyway (navigations should primarily happen due to user interaction), and queue is an even more special case.

It would be much simpler to internally create the reference implementation for all applications and call it done

I don't think there's any general solution for this, but feel free to suggest ideas. Maybe the documentation can be improved to make it more clear.

Would the authors of React Navigation consider adding a PR with this functionality or would they consider PRs from contributors?

You should first create a proposal about what's going to be in a PR.

[satya164]

If you use the built-in deep-linking API then this isn't an issue. Opening deep links when the app is first started shouldn't be handled by navigate actions, but rather with the initial state, which the built-in deep linking API abstracts out and handles. The linking API is customizable enough to fit any advanced use cases, so it negates the need for custom implementation.

You should be using the built-in linking prop and customize that to your needs instead of implementing deep link handling by yourself.

[pke]

I found the linking prop limiting in some ways as it can lead to confusing navigation patterns.

Lets say I am on Stack A with Screen AA and its link is (/screenA).
And now a deep link opens Stack B with Screen BB the back button on Stack B will not point to Screen AA, where I have been previously but to the root screen of Stack B. That is confusing.
Current deep links don't honour the current stack/screen and there is no way to configure a link to point to different screens depending on the current navigation stack.

[satya164]

deep link opens Stack B with Screen BB the back button on Stack B will not point to Screen AA, where I have been previously but to the root screen of Stack B

That's not the default behavior and is only like that if you explicitly specify initialRouteName in linking config. You can even fully customize what state gets rendered by using getStateFromPath if you need that.

Anyway, nothing prevents you from using the ref yourself. The linking prop still uses the ref internally, it just takes more code to implement yourself - which is fair if your really really need to customize everything, not every use case can be supported with a built-in feature. I just haven't found such custom implementation to be necessary in any app I worked on.

[pke]

So having 2 stacks in a BottomTabs navigator:

<Stack>
  <Screen A>
  <Screen B>
</Stack>

<Stack>
  <Screen C>
  <Screen D>
</Stack>

We start at Screen A -> B -> D. On D going back would go to B and not C by default? So if that doesn't work, and Screen D doesn't even offer a back option (but Android back still works) then something in our configuration is broken?

[satya164]

If you don't want behavior of nested stacks having their own history then you'd have a single stack at root instead of nesting them inside each tab.

But what does it have to do with linking config? That's how nested navigation works in React Navigation. It's not going to work differently just because you used the ref instead of linking prop.