Nested Navigators Re-render the whole tree

[TwistedMinda]

Hi!

I really tried to search on google & this repo's issues or discussions but without success. I'm posting in Discussion because I know that my problem is an intended behavior but I wanted to know what can be done about this.

So I have a deeply-nested navigator architecture with a Drawer, BottomTabs & a Stack inside, of course.
The bottom tabs are not smooth, simply putting blank <View /> instead of my screens show the same lag on lower-end android devices than with my screens fully rendering.
I used React DevTools of course to find out where is the problem, and all the render time is taken by the navigation tree re-rendering all my navigators.
It makes sense because in the code the state of the parent navigator changes when a child switches screen, which causes the re-render of the library's component.

Here's how much time it takes to switch tab on the ios emulator which should be able to maintain under 16ms with blank screens, but it bearly does:

It seems that re-rendering the tree is way too much. Am I missing something? Is there a reason for the absence of memoization or layering so that only modified navigators switching screens would re-render.

I really want to have a smooth navigation experience and right now I really don't see what to do to go further. I don't really wanna migrate to RNN as I need a lot of customization.

Thank you for reading, appreciate you taking that time!
<3

[satya164]

The navigation state is stored at the root so memoization can't avoid re-rendering the whole tree. What can be avoided is re-rendering of any individual expensive components. If you can identify any specific components that are expensive to re-render then PRs are welcome.

Whether you have an empty view or not shouldn't matter because your screens don't re-render on navigation. You're also measuring in development mode which is less performant.

[TwistedMinda]

@satya164 Thanks for your answer!
Yeah, I don't believe there are many expensive components that could be memoized in the library, I suppose it would've been done already ;)

I'm profiling in development mode so I have a more realistic performance setup: an ios simulator in dev mode is still super-fast compared to a low-end android device (where I see the navigation glitches)

I think the biggest problem is that I'm nesting navigators then.
Maybe I could use a specific library for the drawer and the bottom tabs, this would reduce the navigation tree to only one navigator and therefore improve performance.

Does it seem fair enough?
Is there any good stuff that I'm gonna be missing by not using TabNavigation and DrawerNavigation from react-navigation?
Do you see any other option?

Thanks again!

[TwistedMinda]

Just to follow up the issue:

• migrating navigation-based drawer to react-native-drawer-layout (which is the one used in react-navigation under the hood)
• migrating BottomTabNavigator to my own system

altogether fixed my nested navigation pattern and my app is now blazingly fast!

It also helped for lower-end Android devices to delay screen content apparition:

• use navigate() to a blank screen
• use InteractionManager.runAfterInteractions() to delay content:

const MyScreen = () => {
  const [visible, setVisible] = useState(false)
  useEffect(() => {
    InteractionManager.runAfterInteractions(() => setVisible(true))
  }, [])
  return visible ? (
    // ...content...
  ) : null
}

[jjspierx]

Thank you TwistedMinda. I was having this exact problem with a tab navigator nested in a couple of other navigators, with a drawer navigator at the root. I was able to mitigate the problem by doing all of the business logic in the component that hosted the tab navigator. This at least made it so that when all my tabs re-rendered on every switch, the business logic wasn't running every time (api calls, etc...). However, eventually as my app grew, it was causing flickering to happen when tabs switched, and other odd visual issues with components that had animation, which were then re-animating on every tab switch. I took your suggestion above, and ended up swapping out MaterialTopTabs, with react-native-tab-view, the underlying component directly. While it wasn't a direct drop-in replacement, after a day of work, it now works great. No more tab re-rendering of every tab when I switch tabs.

One thing to keep in mind when using react-native-tab-view, or any other tab component, is that it is not integrated with react-navigation, so can't navigate to it navigation() functions. However, I found this is easily worked around.