Migrating from wix/react-native-navigation

[karlsander]

I'm evaluating moving an app from RNN to the Navigation Router, and in my first experiments it seems to be going well. I don't think I will miss any features. What I'm wondering is: are there any pitfalls? Has anyone else done this?

What I am worried about is performance / responsiveness / native quality, and I can't quite test that in my POC. RNN is a chore to integrate, but it gives me a certain confidence that navigation in my app is going to be rock solid. Everything will still be smooth when the JS thread is busy, I can push 300 screens and the RAM usage will not explode, one screen/tab can crash and the user can still navigate back to a working one, etc.
So I would like to know if there is a difference on a conceptual level that might make Navigation Router less reliable? RNN is making me wrap each screen with all my providers and Navigation Router doesn't. So I assume RNN creates a React root surface for each screen and Navigation Router doesn't. What are the consequences of that?

In my migration, it seems like I'm going to be recreating the same StateNavigator that contains all my screens for each of the app tabs, because every navigation is allowed everywhere. Is that the right thing to do?

One feature I might miss is the config RNN offers with waitForRender (or not) on navigations and onSwitchToTab for tab rendering. Those really help make the app responsive on low end android devices, but I can probably work something out with the lifecycle hooks.

If I'm going to do this migration, I'd be happy to write up a guide along the way, if that's something you'd be interested in adding to the docs.

[grahammendick]

Seasons greetings and thanks for starting a great discussion.

I’ll tell you something funny. In the Navigation router v2.0, the navigation worked in a similar way to RNN. You registered each screen separately and the Navigation router mounted them as root views on each navigation. But there are 2 big problems with this approach.

1. Screens don’t share React Context. The only way you can share data between 2 screens is with a global store library, e.g., redux.
2. The navigation starts before the screen has rendered. This means the user sees a blank screen at the start of the transition. I’m guessing RNN introduced waitForRender to workaround this problem rather than to improve responsiveness.

In the Navigation router v3.0, I changed to a single React root for all screens and suggested to RNN that they should do the same. This is the same model that React Navigation finally adopted with React Native Screens.

The Navigation router uses the native navigation primitives on both Android and iOS. It uses the FragmentManager on Android and the UINavigationController on iOS. Neither RN nor RNN use the navigation primitives on Android. Although RN does use the FragmentManager, they have rolled their own stack management. I suggested they switch to the native stack management to avoid the profiler reporting memory leaks.

In my migration, it seems like I'm going to be recreating the same StateNavigator that contains all my screens for each of the app tabs, because every navigation is allowed everywhere. Is that the right thing to do?

Yes. You can create a StateNavigator from another one, for example, const tab2Navigator = new StateNavigator(tab1Navigator) like I did for the tabs in my twitter sample.

I hope this helps you feel comfortable switching to the Navigation router. If there’s anything I didn’t address or you have other questions please let me know.