Spike: POC and report on new Navigation library

[J-Son89]

The current navigation library poses many issues.

We want to do a small time boxed investigation on using the library:
https://reactnavigation.org/

This should investigate how:

• Home tabs will work,
• navigation performance,
• transitions,
• handling complex navigation paths,
• Managing the status bar

The output should come in the form of a workable POC for some parts of the application and ideally can have a workable proposal for how an iterative migration to this library could happen. (e.g migrate certain parts of the application).

[ulisesmac]

@Parveshdhull @flexsurfer

This PoC won't be implemented now since we have other priorities, but it'd be great to also have your POV on the trade-offs of this change.

[flexsurfer]

#12141 This might be helpful, i think for v2 reactnavigation.org/ should work better

[flexsurfer]

actually we don't need POC , we already know it will work and POC will be just implementation, it's not that difficult, this also might be useful https://www.notion.so/Navigation-597d2359318d40b89a5d90d57cf08910

[J-Son89]

actually we don't need POC , we already know it will work and POC will be just implementation, it's not that difficult, this also might be useful https://www.notion.so/Navigation-597d2359318d40b89a5d90d57cf08910

In a vacuum this statement is true, but right now we have several critical releases ahead of us. For these releases we want to keep the app in a releasable state at all times.
As such changing the navigation library is high risk to do that as there is just many blind spots we cannot know of until we use it. It will likely be a huge and disruptive change to the codebase and we want to explore if we can do it iteratively to mitigate some of that risk.
Further, changing the navigation library is low priority compared with many other items on the current roadmap.
A POC will help us understand how much effort is involved with the migration, hopefully detect a few unknowns, and add weight to what actual benefits we get from this migration apart from a nicer api etc. it is not wasted work as it can serve as a reference and can speed things up a lot when/if we eventually make the move much later/ perhaps even next year.

@ulisesmac & I have found an opportune time to do this POC just after 2.30 release. 👍

[Parveshdhull]

hi @flexsurfer as per the notion document

RN has only one root, its RN root component, and all navigation will be always in the RN tree, just views will be not active

I am curious about how RN will address the performance problem of having a big RN tree. By views not being active do you mean subscriptions will not be triggered there? We cached subs and stopped triggering subscriptions also in the case of jump-to, still performance was affected. So I am a little worried that migration to RN might bring those problems back, wdyt?