search

callstackincubator / bs-react-navigation

A fast, declarative navigation for React Native, based on React Navigation
MIT License
55 stars 5 forks source link

Consume packages of React Navigation #6

Closed grabbou closed 5 years ago

grabbou commented 5 years ago

This is more of a long-term goal, or at least a thing to do once the initial release is made.

Right now, we bind to react-navigation package and provide an interface to its high-level API. This is the easiest and fastest to do.

Unfortunately, this approach has several downsides, including the support nested navigators without employing major hacks and working around the default way of declaring routes, which is a statically-defined hash map.

For context, in here, we register a single screen statically (called Container) and resolve what screen to render based on a switch/case statement. This allows us to use Reason pattern matching w/o paying performance penalty.

What we could do to make it better is to consume ingredients of React Navigation, now that it's split into separate packages. This would allow us to provide a custom implementation of several packages yet still use the same transitioner and components that React Navigation uses in Javascript realm. In other words, instead of binding to the entire react-navigation package, we could bind to react-navigation/core etc.

Leaving this open for further discussion. I suppose several ideas will pop up in our heads automatically once we finish initial support for the most popular navigators and are aware of all the limitations our design decisions have on this project.

czystyl commented 5 years ago

It's happening already and necessary because of the stuff you mentioned. Unfortunately, some of internal helpers/utils form the react-navigation are not public exported. So rewriting the Stack router force us to write some of those helpers from scratch - so is not so hard to do.

czystyl commented 5 years ago

I'm closing the issue because it's already done.