Why is NavigationExperimental part of react-native core?

[akupila]

The work done by @ericvicenti is great but the API is still quite unstable, documentation missing etc. I think adding another navigator in addition to Navigator and NavigatorIOS will confuse people more than help them. As NavigationExperimental was pulled in from ericvicenti/navigation-rfc i'm sure there's a reason for this?

Pulling out NavigationExperimental into it's own repo, for instance facebook/react-native-navigator-next, has a couple benefits:

• Allows API, docs and examples to stabilize independent from react-native
• Issues & pull requests can be tracked separately, generally less clutter in main repo
• Potentially less confusion for people looking for a navigation solution, having it part of core (and in UIExplorer) makes it currently look like an officially blessed way of doing things

Navigation is a such a core part of any app and i love the thinking that's gone into NavigationExperimental. Would be great to get NavigationExperimental to a good solid place and only then recommend it as the way to do navigation.

[eysi09]

I completely agree. I've put a lot of effort into getting the Navigator component to work the way I want it to. I decided to stick with that component since I assumed it would be consistently maintained and improved by the core team and community. Now I'm not sure whether that was a good move or whether I should start worrying about switching to the NavigationExperimental version. Navigators are a core part of any app as @akupila mentioned and replacing one Navigator for another in a non-trivial app can be huge amount of work.

Should I commit on the Navigator component and continue development with it's API in mind or should I avoid putting much effort into navigation related logic and be prepared to switch in the near future?

[satya164]

@akupila

The work done by @ericvicenti is great but the API is still quite unstable, documentation missing etc

Even if it's in the main repo, it's named as NavigationExperimental, which should be enough to imply that's it's experimental. Of course, before finalizing it, we will need to improve the docs and all.

IMO putting it to a separate repo will increase the maintenance cost rather than decreasing it. And we'll need to have tooling for 2 different repos.

@eysi09

Your reasons are completely different I think. I think we can move the current Navigator to a separate repo when NavigationExperimental becomes the default navigator. Same goes for NavigatorIOS. People who are already happy with the current navigator shouldn't need to change anything.

cc @ericvicenti

[geirman]

I decided to stick with that component since I assumed it would be consistently maintained and improved by the core team and community.

@eysi09 Doesn't appear to be a safe assumption. Refer to the Navigator Comparison Docs which state...

Facebook is dropping support for Navigator and will focus on NavigationExperimental from now on

[rclai]

I was under the impression that it was going to replace the current Navigator given the way the Product Pain post was titled? Can you guys clarify on this?

[eysi09]

@geirman You're right, thanks. That comment is only 22 hours old though, wish I would've seen it last week. Is there a rough estimate for when it will become the default? And is it production ready at the moment (apart from the missing docs)?

[satya164]

@eysi09 Using it in prod and it's working fine. But the API is still in flux. So may be hold off a bit.

[akupila]

I think my biggest issue here is that it's a bit unclear where discussion or questions should happen. Previously an issue could be opened on the ericvicenti/navigation-rfc/ repo but now i just feel bad doing it as there are so many open issues in the main repo already. Same thing goes for community contributed docs updates, examples etc, what's a good approach for that now?

@satya164

IMO putting it to a separate repo will increase the maintenance cost rather than decreasing it. And we'll need to have tooling for 2 different repos.

As NavigationExperimental doesn't depend on any native code (just Animated which already is in core) i don't think the tooling overhead is that bad. Sure there's some with setting up tests etc but that applies to any 3rd party library. In a sense this is very similar to reactjs/react-router which happily can live outside of React core.

All this said I think React Native is a bit different that React; an app without navigation is basically non-existent in the native world so eventually it'd be good to have a core team blessed router part of core and UIExplorer. I just don't think NavigatorExperimental is mature enough for that yet and keeping it part of core slows down progress. Happy to be proven wrong!

[satya164]

I think my biggest issue here is that it's a bit unclear where discussion or questions should happen. Previously an issue could be opened on the ericvicenti/navigation-rfc/ repo but now i just feel bad doing it as there are so many open issues in the main repo already. Same thing goes for community contributed docs updates, examples etc, what's a good approach for that now?

Discussions should happen in the main repo. Keeping it in the main repo means more people will try it, rather than only few people who discover that another repo exists.

@ericvicenti should the other repo be deleted/or issues could be disabled there?

As NavigationExperimental doesn't depend on any native code (just Animated which already is in core) i don't think the tooling overhead is that bad. Sure there's some with setting up tests etc but that applies to any 3rd party library. In a sense this is very similar to reactjs/react-router which happily can live outside of React core.

There is a lot of tooling needed, bots for importing PRs to phabricator, bots to comment on issues, running tests on CI, syncing the code into FB codebase etc. Even now it's pretty huge work load to keep everything working properly and fix bugs. Splitting it into two repos will be immensely difficult to manage.

Also after it's finished, when we've documentations, examples etc., it'll be much harder to integrate them back.

I just don't think NavigatorExperimental is mature enough for that yet

NavigatorExperimental is being used inside Facebook. It might not be mature, but it works pretty good right now. Also it's named as Experimental, so I think its obvious that the API is not stable.

keeping it part of core slows down progress.

I don't think it slows down the progress. Why would you think so?

Note that all of these are my personal opinion. I understand why you're saying this, but I don't think it makes much sense in context of React Native.

[akupila]

All valid points. I didn't consider the depth of the tooling needed as i'm not all that familiar with the build process & CI here.

I guess it makes sense to fix forward rather than reverting back and keeping everything in one place is definitely a good thing for anybody in the future googling things. Would be nice to clear some confusion here though, perhaps by adding something about NavigatorExperimental to Navigator Comparison, maybe merging stuff from ericvicenti/navigation-rfc/blob/master/Docs/NavigationOverview.md? I'm also curious to know if there's an ETA for this to be finalized? Or at least for some basic documentation to show up?

[ericvicenti]

Thanks for the constructive discussion around this, folks. I agree that we're not in an ideal state. @satya164 is right, we have it this way for now for maintainability reasons. It is much easier for us to open-source RN modules this way because of shared testing, code syncing and versioning infrastructure. We also want to make it clear that NavigationExperimental is going to fully replace Navigator (which is already in RN core).

I'm working on documentation today and I hope to get some of it landed in the main RN docs by tomorrow. I know its a big concern for adopters!

I agree with @akupila about the biggest problem- that GH issues inside the RN repo will not scale well. At the moment I am happy to respond to issues on the RFC repo, or when people tag me on issues in RN. Otherwise I'm afraid that I will miss things. Does anybody have any suggestions? I could close issues in the other repo, but it still might be a useful channel. Maybe we can add a label for this and configure a bot to tag a few of us Nav-heads?

cc @vjeux , there are a lot of shared concerns with this and Animated.

[vjeux]

For animated, work on a next version is being done on https://github.com/animatedjs/animated in a very ad-hoc way. Unsure if it's a path we should follow

[rclai]

Thanks for confirming and clarifying. Can I ask questions about NavigationExperimental here?

[geirman]

Would it make sense to start a #Navigation or #NavigationExperimental channel in Discord's reactiflux? Might cut down on the random, one off questions... leaving github issues focused on work items.

[ericvicenti]

Ok, lets do this for now:

Questions on Usage:

Post on StackOverflow and tag @ericvicenti . Long term we should create a tag for this that people can subscribe to (I would do it but I don't have enough SO reputation)

Bug Reports and API feedback

Post issue in react-native and tag me (@ericvicenti). Title should include "NavigationExperimental"

OR:

Post issue in https://github.com/ericvicenti/navigation-rfc/issues

Neither option will be appropriate long term. I'm open to ideas on how to fix this!

Discussion

We just opened a new discord channel. Feel free to drop in here and discuss: https://discordapp.com/channels/102860784329052160/154015578669973504