Will RNN be relevant once fabric re-architecture lands?

[SudoPlz]

Hey there,

this is not an issue, and please feel free to close if I'm breaking a rule here, but I was really wondering if it's worth the vast amount of time to migrate from v1 of your library to v2, considering the fact that the react-native re-architecture (that currently goes under the name fabric) will land soonish.

If we have direct communication of the js layer to the native layer without a bridge, what's the purpose of native navigation?

Just wondering, and sharing my thoughts.
I'm super curious about what you think!

Thanks

[kneza23]

It seems to me that RNN is kind of laid off (maybe im wrong). Lots of issues here on Github are coming up, but as i see it there are just left there (without any discussion). Seems like only 2 people are working on maintaining the library. I hope this is not the case and we will see some new stuff from RNN team and issues to be addressed.

RNN is the only good native navigation library that we have in React Native ecosystem, it would be shame that it goes to waste or deteriorate in quality because of lack of maintaining and development.

As regarding your question about Fabric. I have no idea. Maybe someone has more info?

[pribeh]

I predict that fabric will become available later this year since it's a major initiative requiring a lot of rewiring of RN. When complete, it will take some time to iron out the kinks, create new documentation, and on top of that will require a lot of learning (new API?).

If you want the most optimized native navigation library out there that works right now, use RNN. If you want to further native gesture and animation support use react native gesture handler and reanimated. The three combined right now offer amazing performance, are all expertly maintained and well documented.

@kneza23 The maintainers have done a superb job of getting version 2.0 ready for production (working quite well in our production apps). It's quite difficult to maintain such a versatile library, used by so many (123,166 weekly downloads!), and which can be used in so many different ways.

[grahammendick]

@kneza23 React Native Navigation is a great native navigation library but it’s not the only one. You should take a look at the Navigation router. It’s 100% native and supports a wider variety of navigation patterns than RNN

[kneza23]

@pribeh Dont get me wrong, RNN is really good and as i said it the best one that we have. But i have encountered a couple of really annoying issues. On iOS especially regarding topBar, largeTitle and searchBar inside the topBar.

For example:

• iOS: search bar is not visible in the first bottomTab screen when you call setRoot (you need to set it dynamically in the Component that give you janky animation because it just pops in when screen appears)
• iOS: Large title navigation bar snaps on scroll instead of smooth transition (you need to set drawBehind for it to work right, but that can mess up other parts of UI like sectionList) i have reported it here already iOS - Large title navigation bar snaps on scroll instead of smooth transition #4791
• iOS: When you toggle searchBar for typing on the topBar the largeTitle disappears/scrolls up (like it should) but, when you then change tab and go back to the that screen with searchBar, the largeTitle is suddenly there.
• iOS: You can't remove border on topBar when you have searchBar
• Android: on first setRoot call when your layout is bottom tabs, first bottom tab that is shown has no selected state/icon. You need to dynamically call it to be set even though you have defined everything when you have called setRoot

...there are more of them, forgot the rest :)

These are just some of the problems that i'm facing and i'm leaning to discard both largeTitle and searchBar on iOS. It is frustrating because these both features have become really standard in native iOS navigation and they really improve UX/UI.

[jinshin1013]

I totally agree with @kneza23 regards to the amount of community participation in this library is quite lower than those other navigation libraries such as react-navigation. And the rate of getting something fixed is also quite lower than these other libraries. I know these guys have been working extremely hard to get to V2 and I've seen the whole process. But I think it's now time for community to join and also start making PR to address some of the persistent and tedious issues such as topBar, custom transitions and more. I've started to learn native languages in a hope that I could begin contributing to this library because I enjoy using this and I think we all do.

[guyca]

Re the future of RNN in regards to fabric. I honestly think it’s too soon to know for sure how fabric will affect RN and other libraries. While I think we can assume it will have a positive impact on Js based navigation libraries, we can’t say for certain if it will solve all of their major pain points which, in my opinion, are keeping navigation business logic in Js domain and contributing to large shadow dom trees.

If I understood correctly the intent behind the fabric re architecture, it’s meant to address the asynchronicity of RN. It addresses that issue by sharing memory between c++ and Js realms and exposing an interface which will allow developers to communicate between these two domains synchronously. Libraries will be able to leverage these new tools through TurboModules. This sounds very promising, seems like big refactors are ahead of us.

RNN’s main concern was never the bridge or the asynchronous nature of RN. Our main concern was to do minimal work on the Js thread. That’s it.

We’ve mostly achieved that by doing the following:

1. Keep all navigation state in native - make no decisions in Js realm. The sole responsibility of our js code base is the handle commands (push, pop etc.) and to allow users to react to navigation events (screen visibility, button click etc.)
2. Create each screen in a separate react root view. Meaning we treat each screen as a react application (with its own shadow dom). While we’ve never measured this, when we first started developing the library it seemed to have a very positive impact on responsiveness. I believe this still holds true today.

I think these two aspects of RNN will still be relevant after fabric lands.

Well, these are my thoughts for now. Let’s keep the discussion going as more concrete info is available to us.

[grahammendick]

Fabric, by itself, won’t put the performance of JavaScript navigation on a par with Native navigation. It’s not so much the bridge that slows the JavaScript navigation down. It’s more that React might be too busy rendering the new screen content to keep up with the navigation animation (since they both happen on the JavaScript thread). React Suspense combined with Fabric might level up the performance. Suspense allows you to assign different priorities to different renders. To avoid dropping frames, you’d give the navigation animation the top priority and the new screen content a lower one

Even if, one day, JavaScript navigation doesn’t have performance problems, that won’t spell the end of Native navigation. The beauty of React Native is that you don’t compromise the UX. React Native uses the same fundamental UI building blocks as regular iOS and Android apps. Native navigation sticks to this philosophy but JavaScript navigation doesn’t. No matter how hard React Navigation tries it can never replicate the Native navigation look and feel. For example, If Apple revamp the navigation bar between versions then every React Navigation app will instantly look outdated!

@guyca I’m surprised you think it’s good to "keep all navigation state in native" because I think that’s React Native Navigation’s biggest weakness. The Navigation router, the only other 100% native navigation library, holds a representation of the Native Stack in JavaScript. This means the Navigation router can support more navigation patterns than React Native Navigation, like jumping forward and backward through the Stack and replacing any scene in the Stack.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If you believe the issue is still relevant, please test on the latest Detox and report back. Thank you for your contributions.

[stale]

The issue has been closed for inactivity.

[grahammendick]

Create each screen in a separate react root view.

@guyca I've recently changed my Navigation router from one root per screen to one root for all screens. It solves a lot of problems so I recommend you revisit your decision. A key problem it solves is that all screens share React Context so you can use any state management library or none to share data between screens. Also, the render happens before the native navigation so you don't have to waitForRender anymore. That also means that you can do away with your static options object and use React components instead

[SudoPlz]

@grahammendick what about animation segues, if you only have one native screen and one root view, doesn't that mean that segues will be handled by react native and not get actual native invoked navigation segues?
The way you wrote your question above makes me think that there's no point in using native navigation anymore. Can you please clarify? I'd be grateful.
Thanks

[grahammendick]

You still have multiple native screens. Changing to one React root for all screens doesn't change how you structure the native side. That's the beauty of it. You have one root on the React side so you get all the goodness that React offers. You have multiple screens on the native side so you keep the goodness of the native side, e.g., segues

[SudoPlz]

@grahammendick How can you have multiple native screens, but one root view?
Will all of the native screens have that one root view as their child, and then you'll be changing the content of that root view upon every screen change?

[grahammendick]

On the React side you create a Stack component. This component renders an array of scenes. When you navigate it pushes the new scene onto the array.

On the iOS Native side you override the insertReactSubview method, called whenever the new scene is rendered. You push a new UIViewController onto the stack and set its view content from the rendered subview.

The Android Native side is similar except you start a new Activity instead of pushing a UIViewController.

[SudoPlz]

Interesting approach, thanks @grahammendick..