React-native-navigation: [V2] is it fair to recommend people to move to v2 while it's mostly broken and not ready for production?

[terreb]

Issue Description

I moved from v1 to v2 since the docs recommend to do so, plus I had some issues with the v1 that won't be never addressed since the devs had dropped support. But those issues were not that crucial (code push didn't work properly and e2e tests) the navigation itself worked. Now when I switched to v2 I've been encountering dozens of issues and crashes. Almost everything is broken if I try to apply styles or do something a bit more sophisticated than a usual stack of screen. TopBar, BottomBar, Drawer are all not working properly. I see multiple other issues have been created on GitHub and most of them get label stale. I do understand that devs are busy with developing the plugin and can not react on all the issues.

My only question is why you recommend to migrate/start with v2 while it's in alpha and far from being ready to use in production and not mentioning this anywhere in docs?

[santanu4ver]

I wonder if dev even has enough energy/wish to address this question. Also started thinking if going back to v1 would save me some time to do actual development other than spending on nasty bugs in v2 when most of them not sure when to be address.

[jengo]

I've been learning React Native and I have been spinning my wheels just trying to get any basic navigation to work. I've been back and forth on libraries. I've found v2 to be horribly broken for me, and so little documentation that it's impossible to make anything look and work correctly.

I know the devs are hard at work on v2 and I am looking forward to a stable version. Personally, I think it's way too premature to suggest using v2 in the documentation. Not until it's at least beta level quality.

[ericketts]

its also disappointing that there's a freeze on accepting PRs for V1, so a PR I put up fixing crashes caused by ReactInstanceManager.recreateReactContextInBackground() just sat there until the bot marked it stale and eventually closed it; I get the rationale that the devs want to focus on polishing V2, but until V2 is ready for primetime, V1 should be supported and fixes for bugs in V1 should be merged.

navigation is really something that needs to be part of react-native core for it to ever be a serious replacement for native development (and you know that facebook almost certainly has at least one in-house nav lib, likely with a high level of polish given the amount of man hours they're able to devote to such a thing...)

Edit: the PR I mention actually was eventually merged into V1! so my criticism there is far less valid... and as I've worked more on the project I've gained more and more appreciation for just how much work has been put in to this lib, which wix could've easily kept private, so I'm very grateful they decided to open source this project because homebrewing a solution could be a full time job. few things ever reach perfection, if you want to help get this lib there pick an issue and hack away!

[FeniXenAaaa]

Well, even if new version has lack of documentation and is unstable it does make sense to start new project with it. Because you don't want to start brand new project with something that is outdated and probably won't be maintained in future because of fundamental problems, right?

[terreb]

@FeniXenAaaa, yes makes sense, but only if you plan to have a production release in say 6 months or so, and if you have plenty of spare time trying to workaround/fix dozens of bugs. Sure you may be lucky enough that with your requirements for the navigation it just works for you.

[FeniXenAaaa]

@terreb yeah, probably they could be more precise on what version when to use. But you as an experienced developer with RNN V1 should understand that V2 is in alpha and it is absolutely new because it has new fundamental approaches therefore it will require a lot of effort to get familiar with it. And of course it shouldn't be a choice when you have release less than in a 6 month. It is obvious that if you need to bootstrap something quickly a tool that is in active phase of development (without stable releases so far) shouldn't be considered to use.

[terreb]

@FeniXenAaaa, this is great if reading "New to RNN? We recommend you start with v2" all those things you've just written are obvious for you;) I doubt any one else new to RNN reading their statement understands how far the current state from a stable release and don't know that after installing v2 he/she will be get involved in an endless game on how to make work one thing without breaking another.

[rat-moonshine]

Wix doing a great work to help the community roll the RN stuff, which is appreciable. Along with that (IMO) to roll the transition smoothly, it could have been great if they offered following things (as one already suggested by one at here):

1. Accepting nasty v.1.0 bugs
2. Having some lines added pointing possible breaks if go by v.2.0 as Airbnb did! So people having a timeframe to release by next 6 months their project, can decide between things:

React Native Navigation by Wix engineering is an alternative library that uses "Native" navigation components of each platform, and has been around longer than Native Navigation. If you need a stable / production-ready navigation library today that uses native platform based navigation components, we recommend you check this library out.

BTW, one can debate 'alpha' means breaks and bugs so you have to wise enough to understand xD ; And the above lines from Airbnb possibly marked for v.1.0 ;)

[adamterlson]

I just wanted to take a moment to briefly share my own experiences migrating from V1 to V2. I hope it will serve as a cautionary tale for others who find this thread who are considering switching to V2.

Migrate from V1 to V2—What could go wrong?

The root cause of us wanting to switch away from V1 is the tabBar flicker issue mentioned here, here, here and here (and probably others).

Needing to use Redux, I found immediately that the documentation was wrong about how to do that. There were numerous times were I found the documentation for V2 missing or inaccurate in its methods or arguments.

The first plan to fix the tabBar flicker issue was to have tabs within a stack, rather than a stack within each tab, so a pushed screen would simply totally overlap the tabs. This fixed the tabBar flicker issue alright, but created another issue: if you switch tabs and then push a new screen, both the root topBar and the pushed screen's topBar would be displayed. You could "fix" it by wiggling the screen during the left swipe animation.

It's currently not possible to change the color of the back button.

Having a custom topBar component across multiple tabs results in a re-render on every tab switch that is visibly slow.

It's not possible to perform a screen pop using the id of the stack, one MUST use the id of the top-most screen on the stack. If you attempt to use the id of the stack, it will pop successfully, it will just break all subsequent navigation (the new screens mount—you can see the actions get dispatched on mount—but they are totally invisible). This issue makes it not possible to reliably navigate backward from something like redux-saga. You might think that you can just track what page is on top of the stack manually, but guess what, the back event isn't supported for swipe, android back, and the topBar back button, so it's impossible to track.

The app crashes on iOS when you attempt to set { transparent: true } on the topBar of a modal screen on XCode 10.

Imagine you want to have a topBar with a background color that starts transparent but as the user scrolls, it fills in with color. Rather typical. We solved this in V1 by just hiding the topBar entirely and rendering it all on the JS side. In V2, there is a massive animation jank when going from a screen with topBar: { visible: false } to a screen with it visible. So, rather than hiding the topBar entirely, I set a custom topBar with { topBar: { component: { name: 'MyNavbar' } } }, but this custom component does not draw behind the statusBar no matter what you do.

I could continue with more issues I faced.

Instead of continuing with this effort, I was forced to abandon it. Instead, we will continue to use V1 and will change the design of several screens throughout our app so that we no longer require hiding and showing the tabBar, the cause of the flicker.

This redesign of the screens around the V1 issue we faced is a more stable, less risky, and cheaper approach than it is switching to V2.

In Summary

For those considering upgrading from V1 to V2, if V1 works (or can at all be made to work by perhaps changing design requirements), DO NOT DO IT—the result will almost certainly be better outside of perhaps only the most trivial of navigational requirements.

For the maintainers, thank you for all your hard work! The React Native community seriously needs you, and I believe needs react-native-navigation to be successful. However, until such time that V2 has been put through its paces and the numerous, serious bugs resolved, it only damages the community to push V2 adoption broadly and to discontinue support for V1 prematurely.

[ethaizone]

I think I found many problems after I use V2. In case XCode 10 I think it's not main issue because this update is not long and any library can break from its change too but I found another issue that shouldn't found on V2.

Example this pull-request #3833 that I tried add onNewIntent on v2. OK. I tried make pull-request but it can't merge because some not stable branch make failed test result and _No any info that which branch that I should make contribute_.

It's not really important except one thing. _Why do I need to create that pull-request at beginning? On V1 we have onNewIntent normally and this is really basic method that all React Native project should have it. Why does it disppear from v2?_

It's question in my head that v2 is really ready for production or not. If I answer this question, I think it not for production right now.

We can't blame anyone. It's just that we place trust on wrong place.

[howg0924]

I recommend people with tabBar flicker issue to give pribeh's method a try:

https://github.com/wix/react-native-navigation/issues/2184#issuecomment-397830334

It solved the issue for me (V1). The main concept is to give the screen with tabs a fixed height.

@adamterlson

[stokesbga]

React native is, at its core, a hack. Trust those of us who have been building with it since 2015, there will never be a solution that just works 100% of the time. RNN V2 is extremely frustrating and stressful to migrate to, but you can get a working solution. After a LOT of refactoring, quick fixes, and separating android and ios components, it will work. It is no more or less stable than V1 imo, and I'll kill myself before I go to react-navigation. That lib is maintained by assholes... and worse, facebook.

[putuyoga]

need suggestion, for new project, is it worth to adopt RNN v2? i won't comeback to react-navigation because at the past we suffer performance issue

[santanu4ver]

@putuyoga You really asked this after reading all above 'user experiences' (?)

[I am already a dead man]
Wix needs QA persons for v2 so you can contribute!

[thinklinux]

I started a new project with V2. I didn't have a lot of big issues so far. And the thing is that it's going to be ready sooner or later and I don't want to migrate when my app is ready. At least not that soon. So I prefer going with V2 and opening issues. Also making PRs if I have the time for it.

[lukebrandonfarrell]

@thinklinux I agree. V2 has made some significant progress in the past few weeks. If we all come together as a community to spot issues and make pull request it will be a great library in no time.

[stale[bot]]

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[bot]]

The issue has been closed for inactivity.