This gist is designed to provide a way to conditionally navigate multiple stack navigators depending upon the current route.
The use case for this is if you want to have multiple stacks visible at the same time and ensure each can navigate independently, while also ensuring that deep linking will correctly set each stack navigator when entered via deep linking.
For example, if you have a stack on the left side which handles a search screen, and a stack on the right side which displays information about a search result, this would be ideal.
This gist consists of several key files:
- useDualPanelDeepLinking.ts- This is a hook which integrates with the useNavigation()hook from React Navigation V5
 
- This is a hook which integrates with the 
- DualPanelNavHandler.tsx- This is a React Native component that handles the navigation between for multiple stacks
 
- App.tsx- This is an example of a root component, showing how to correctly setup the navigators
 
- NavigationService.ts- This is a basic service that handles the navigation for each stack
 
- RightStack.tsx- This is one of the navigation stacks - in this case, it's on the right-side of the screen
 
- LeftStack.tsx- This is the other navigator stack - this one appears on the left-side of the screen
 
Add the files to your project. Then, in any of your screens, simply add <DualPanelNavHandler /> anywhere inside the rendered contents. I've only tried this with functional components. It might work with React class components too, but I avoid those these days.
Where are the screens?!
You need to add those yourself. This is a proof of concept. The screens have nothing special about them, except importing the DualPanelNavHandler component, and adding it to the render (in functional components, this is the return, and in class components, this is the render() method - see note in Usage section above about this)
What are the @ imports?
Those are typescript alias imports. They point to specific directories which prevents the need to import using relative paths (because import Something from ../../../../../../somePath/someFile.ts is an absolute trash way of working).
Which screens are 'paired' in this example?
In this example, the 'search' and 'train station info' screens are paired. The 'home' and 'blank' screens are also linked. You can see that I've just rendered an empty component for the blank screen - this is for handling the home page, but you could use it for any use case where you don't want content to display on a particular navigator.
Why not use a drawer navigator?
Drawer navigators have some limitations for this use case. For example, you can't use the useRoute or useNavigation hooks inside the drawer since the drawer itself is not a stack but rather just 'static' content. You may be able to use a stack navigator in there, but you'll likely find that you'll have to come up with some sort of solution similar to this in that case.
I personally despise drawer navigators being used as 'permanent side panels' for this reason. It makes deep linking a nightmare to work with, and even handling navigation inside your app becomes a huge hill that you've got to climb (which is uphill, both ways, in the snow, and is littered with bear traps).
Sure, drawers have their uses and I encourage you to use them where it fits, but I am actively avoiding them.
Won't linking 'just work'?
You can only have a single linking (or useLinking hook). This makes sense - if the user is navigating to /search, the hook doesn't know which stack it should work with. You can't have 2 different linking elements inside nested navigators - it just doesn't work.
Isn't dangerouslyGetState() bad?
It's definitely a little bit frustrating at times. Sometimes values aren't defined (this isn't a bug!), and sometimes things are super-nested which makes it taxing to figure out how far down a tree you need to go to get the name of a route for example.
Then again, you're not supposed to use it except in exceptional circumstances. This is one of those times. That's why I built this.
Are there any bugs in this?
Possibly. I'm only human. I encourage you to experiment with this. Adapt it, and improve it.
Could I use more than 2 stack navigators?
Absolutely. I haven't tried, but you could theoretically create an unlimited number of stack navigators.
If you were building an app which displays 6 video streams, you would have to create 6 stack navigators and adjust the code to fit, but theoretically, it should be possible.
Won't that look bad on small screens?
Yeah, absolutely. You'll need to integrate your own screen size handling or hooks to adapt to different screen sizes and scale each stack appropriately. I haven't added any handling for this in this gist. It should be possible without too many issues.
My use case is for supporting a project on mobile, tablet, and the web, and right now, getting multiple stacks working is the priority.
Why not make this a repo with a demo app?
I'm super-busy these days, and while it wouldn't take too long to setup a repo, I opted to use a gist instead. This makes it easier, as you can easily see all the files that are needed, without having to clone a repo or navigate across directories to find the code. In my opinion, this is much easier than having to figure out how I've integrated something, which might not align with your codebase. Less noise is good.
Why not make it an NPM library?
I may consider that at some point. There's parts of your own navigation that will be affected and need rewriting to support this method - it's a lot of work for something that's just as easy as copy-pasting. Plus, if I made it a library, there's that obligation to update it as React Navigation evolves. We've all seen those github repos with issues from 5 years ago, and I'd rather this not be one of those cases.