Proposed changes to native routing and navigation

[AlanSl]

The changes proposed here are to be implemented and tested in the Polaris Shopping demo app first, then, if they work as expected there, backported here.

• [x] Research and explain the planned changes
• [ ] Discuss and agree a new approach changes
• [ ] Implement and road-test in the Polaris Shopping demo app
• [ ] Backport here to Polaris / open banking
• [ ] Document how it works and why

The current approach to routing has been the same since the first commit to https://github.com/nearform/open-banking-reference-app-original-private in May 2019:

• Polaris currently uses different routers for Native and Web.
  • ✔️ This is good: it's the best way to get proper Native transitions without having to roll our own URL handling and back/forward history handling on Web
• Polaris currently uses React Router DOM on the Web side
  • ✔️ This is good: it's robust, actively developed, well documented, well known and widely used
• Polaris currently uses React Router Navigation on the Native side.
  • The benefit appears to be, that the exports are by design very similar to React Router DOM, so the only platform-specific tailoring is that routing.web.ts exports directly from React Router DOM and routing.native.ts exports the same names, but directly from React Router Navigation.
  • However, this also limits the amount of platform-specific tailoring we can do
  • ❌ There are a number of problems:
  • React Router Navigation is not actively maintained. Since November 2019 it has had this status:

    This project is not maintained anymore ... go see react-navigation

  • There are some quite serious reported bugs, such as https://github.com/winoteam/react-router-navigation/issues/90 and we know the team have had some issues with it
  • There were some architecture issues e.g. https://github.com/winoteam/react-router-navigation/issues/54#issuecomment-358151323 to be resolved in a 2.0 release, but that never made it out of alpha
  • Essentially, the project appears to be a wrapper around React Navigation to make it more like React Router DOM, which inherently limits how much of React Navigation we can use.
  • It appears that React Navigation has improved a lot in recent years, and React Router Navigation has not kept pace

My proposal is to use an approach similar to what is described here - https://www.ythecombinator.space/posts/driving-towards-a-universal-navigation-strategy-in-react - based on a case very similar to ours, written on 2020.

Essentially the approach is:

• Use React Router DOM on web and React Navigation in Native (using ^5.X for fully native stack navigation)
• Do navigation via a custom hook that returns a common interface for all platforms, such a memoized navigate function. Maybe call it usePlatformNav, not useNavigation like in the article, because that is the name of a React Navigation hook. usePlatformNav.native.ts would use React Navigation to its full potential without trying to make it look like a DOM router, and usePlatformNav.web.ts would use React Router DOM
• Get data about the current route and history from a custom hook (named usePlatformRoute probably) that returns the same types on all platforms but gets it using the platform's own routing library

Benefits of this approach:

• We're using the recommended routing packages for both React web and React Native

• We don't have any constraints in what platform-specific refinements we apply

• Implementations of Polaris can modify these hooks for project-specific routing needs in just one location so long as it returns the same types

• Components and hooks that use routing can continue to have one routing interface that works on all platforms

• There's a documented case study of it working in production for an app with similar needs to ours

• It's a good accelerator feature: a solution to a common problem that can be modified for project specific needs and doesn't add constraints

  Drawbacks of this approach:

• It requires a little work implementing the hooks, whereas the previous approach was almost out-of-the-box, but given the benefits, this gives us another small unique selling point for the accelerators

• It will need documenting (but we should be documenting and explaining our approach to things like this anyway)

• There are some reported issues with React Navigation (e.g. performance), but this appears to have improved in the last couple of years (especially with 5.X, released Feb 2020)

[AlanSl]

Another possibility is React Native Navigation, which is also endorsed by the official React Native docs. The main benefit of React Native Navigation is that it uses purely-native navigation with a thin JavaScript layer, whereas React Navigation does more in Javascript and React components.

As I see it that is probably more of a drawback than a benefit for us:

• Reduces the amount of customisation that is possible through JavaScript
• React Navigation 5.X uses fully native navigation for stacks, which covers many common cases, so the benefits would be most felt in the kind of apps that need to go very deep into complex Android or IOS-specific native navigation capabilities, whereas we mostly want smooth native transitions between screens, which is well within React Navigation's capabilities
• Slows down development - its official docs expect devs to spend a lot of time in XCode and Android Studio
• It's apparently "a mess" to use with Expo https://expo.canny.io/feature-requests/p/add-support-for-react-native-navigation and in general, integrating it with any React Native infrastructure appears to require a lot of configuration work
• Less widely known and used

However with the approach of forking platforms in a hook, it should be possible that if a rare project did have very niche navigation needs, it should be possible to swap RNN in only changing the logic in the .native.ts custom hook (after getting RNN working with the main infrastructure, which appears to be non-trivial).

[AlanSl]

Most other React Native navigation libraries appear to be simply opinionated layers on top of React Navigation.

React Router Native is different and interesting but appears to not help us get native transitions, which is the main thing we want.

React Native Screens looks like it might be worth using alongside React Navigation. It brings in more native components than React Navigation and appears to integrate well with the rest of our stack. I'll try it and see if it improves things. It's already integrated into React Navigation 5.X

React Navigation is bringing in web support, but it doesn't look ready for production yet. After just 5 minutes playing around with https://react-navigation-example.netlify.app/ I had got it in a state where the browser back button had stopped working.