React-native-router-flux: Why v4 exists if it's based on react navigation?

[Maxwell2022]

I think it would make sense to explain what this lib is offering that reactnavigation is not.

[aksonov]

Good question. I'm going to submit Lighting Talk about it for ReactiveConf:
https://blog.reactiveconf.com/open-call-for-reactiveconf-lightning-talks-2017-a4f5394e5f96

Will post it soon.

[aksonov]

My talk proposal
https://gist.github.com/aksonov/e2d7454421e44b1c4c72214d14053410

[AlmogRnD]

I started with React Navigation and had lot's of issues getting it up and running mostly due to lack of good documentation for complex examples and use cases. I also had different bugs. With all that I also got the very little support I even sent feedback about and question why FB made React Navigation the official router lib, I don't think it should be.

I see React Native Router as a wrapper over the React Navigation API making it much easier to use and better support.

[quadsurf]

@Maxwell2022 this should help when comparing the two of them...

1. react native router flux (RNRF) is more mature and less buggy (only 7 out of ~1600 issues are open, versus reactNavigation that has 75% of their ~1000 issues that are still open (not production worthy, and unacceptable in my opinion))

2. if you're just a programmer, reactNavigation is a great choice, but if you're a programmer and a businessman in need of efficiencies, then reactNavigation is a terrible choice (here's why: reactNavigation is more complicated than it needs to be, and has a much longer learning curve, especially when your app has complex nav requirements and insufficient lib documentation leaves you needlessly experimenting for hours ( i agree with @AlmogRnD )... this is great for the programmer looking for a challenge and wanting to improve their troubleshooting skills, but unacceptable for dev shops or business folk where time efficiencies are needed)

3. reactNavigation, at it's core, does have a nice API, but it's needlessly complex ( i agree with @AlmogRnD )... the purpose of this RNRF lib and what @aksonov is doing with v4, is not to compete with or replace reactNavigation, but to abstract away all of reactNavigation's unnecessary complexity

4. if you're a fan of conditional component/screen rendering, which is a very common pattern in React Native, then RNRF is more conducive to this pattern

5. react native loses its right to call itself an un-opinionated framework when it chooses one library over another (like a government trying to pick corporate winners and losers in the marketplace)... but here we are, in a world where react native chose reactNavigation... i believe aksonov's decision to utilize reactNavigation's api in RNRF v4, was to create "association" with react-native's bias, and maintain this library's relevance... a good move i might add

6. reactNavigation does not have a true modal implementation*, where as RNRF does (and by modal i'm referring to a prompt/alert style pop-up with grayed-out background), and when you call yourself a navigation library, this becomes a glaring/blatant omission i might add

https://github.com/react-community/react-navigation/issues/2031

[Maxwell2022]

It was not just for me but for everyone. This should be added in the README.

Would it make more sense to concentrate efforts on improving react-navigation (core or documentation)?

I've used RNRF in previous projects and I also faced frustration because of the docs not being up to date or information being hard to find. I think it's a common problem for every complex library, documentation is probably the harder part to maintain.

[aksonov]

@Maxwell2022 Improving react-navigation instead?? Maybe you are joking, really. Just for experiment I submitted really useful PR https://github.com/react-community/react-navigation/pull/1999, it took 2 weeks (!) to complete review, I fixed all (!) suggestions from reviewers and after that one from authors said that my PR is not needed because he worked on 'refactoring' of navbar API! Huh, probably new breaking changes... And check other PRs, a lot very useful PRs are not merged for MONTHS.

[aksonov]

And yes, docs are harder part to maintain, especially for open source projects. The problem that most community prefer just to use open source without any contribution.

[marcoj]

@aksonov if ReactNavigation is hard to improve (because of slow PR merge and all) isn't that going to be a problem for v4?

[aksonov]

Many problems like navbar customization (like setting right/left navbar images), action processing (like added missed popTo) could be solved by RNRF.
But for some problems like #2012, yes, we have to wait fix. We could fork ReactNavigation and apply suggested PRs at the future (right, many PR solve problems but still not merged).

Anyway, v3 is based on obsolete react-native-experimental-navigation, so I don't see any better alternative.

[marcoj]

Well I'm implementing the react-native-router-flux on a project right now and I'm keeping v3 for now. I tried V4 and it broke the whole thing.
I think I'll wait a bit for v4 to be a bit more mature and then I'll give it another go.
Meanwhile I'll create a side project to play around with v4 and see if I can be helpful in any way.

[rewieer]

Here are my 2 cents.
I've been using RNRF in one of my project for quite a long time, and these are what I faced :

• transition were painful, I had many transition that would take quite a moment (until many seconds) before starting after pressing a button. And i've for sure used Interaction Manager.
• Routing hierarchy was hard to use. I often took hours before setting things right and be able to move from one scene to another
• Still not understanding what the different PUSH/PULL and other stuff actually mean
• Accessing routing as an implicit dependency rather than having it as a props is particular to RNRF and somehow disturbing. It couples the project tightly to navigation.
• You may say doc are awful about ReactNavigation, but the doc for RNRF is not friendly at all. The Detailed Example never really helped me, and doc doesn't tell much about how it works. ReactNavigation documentation may be broken or some, but I personally never experienced any problem with it, through i'm up to date. I even started to work on a complete rewrite of the doc once but I didn't have enough time to get through it. I believe RNRF doc requires a complete documentation rewrite.

Since I switched to React Navigation, yes there's quite a lot of thing i'm not using yet, and yes it's really a lot of abstraction which complicates things a lot. But so far the only problem I have with it is how painful it is to implement a login system disabling user from going back. With a bit of hacky code it makes through but still, that's not normal. Let's keep in mind that it's young and driven around specific needs. I believe it will get better.

Not intending to spit on your work, guys. RNRF is really an awesome choice, back then it was the best i've found, and many articles on google support it. But I really got frustrated by the problems above. And React Navigation solved them enough to me.

[vexsnare]

Totally agree with @Rewieer

[mirrorshades]

Regarding slow transitions:
@Rewieer are you passing a lot of props or loading data from state via Redux or something similar? Also was this tested only in iOS or android simulators?

I ask because haven't had any problems with transitions. The only time I noticed a slow transition was when I had some buggy code in my react native projects. Something sounds off though.

Sorry for going off topic.

[rewieer]

@typeslower so far it was working fine on emulator but was painfully slow on phone.
I remember back then I was using Immutable with Redux but the entity base wasn't so heavy. I had Redux-Persist with 200ms debouncing as well. So maybe loading data from state using Immutable with sorts & filters could make a deal but, on list of < 100 elements it's hard to think this could have a this huge impact.
Never experienced on IOS because I don't have Apple stuff anyway. This has been tested only in Android. But I remember using other navigation tools was fine.

[hellomaya]

I would say sorry because I am still in the opposite of V4, as I think V3 still the best.

• V3 provide consistency in navigation user experiences across device & system, which I would prefer to the most.
• Yes, in V3 react-native-experimental-navigation is out of date a long time ago, but it still valid to maintain, even though V3 wasn't maintained any longer, I will try my best to maintain a fork copy of V3.
• V3 doc was not good enough? Indeed, it's not a problem, as we can get a slow start, but sooner or later we will figure out everything, it's good, for me it's not enough at begin, not now.
• V4 is pretty much necessary and I understand all of the purpose, but react-navigation is a big concern right now, as I am not ready to dive into it with production app.

By the way, @Rewieer, I have seen the same issue, and I make a bit change to achieve better transition among scenes in navigation, delayed the Animiated.timing in DefaultReducer, to render and finish the scene will go back and forth between javascript core and native code, if they both start same time, this could be a interference. Of cause, to keep major content view show-up only after it finished in Interaction Manager.

Anyway, I still very supportive for the new version, but for now stick to the V3 instead. As I really like that consistency among different device.

[rodperottoni]

It really comes down to how fast you need to deliver your work. I work in an marketing agency environment and RNRF was invaluable to us. There was no time to master the complexity of React Navigation and so we decided to go through with RNRF since day 1. I've had a little bit of pain with the documentation, but nevertheless worked my way through it and delivered apps that are currently running at 60FPS on most devices.
Again - my work is to deliver apps on a certain date. I don't care about if RNRF is an abstraction of other tech. I don't care if one project has 100 opened issues and the other 200. I don't care about the underlying bits and pieces of RNRF. It solved all my issues and I'm 100% happy with it.

[rewieer]

@rodperottoni please tell us more about what kind of complexity you are talking about when you refer to React Navigation, just out of curiosity.

[rodperottoni]

@Rewieer gladly.
Keep in mind I'm not against React Navigation. The reason why I use RNRF is because it let's me do the same thing, but faster. I don't know how to explain, but the developer experience is simply... better.

• For me it makes way more sense to declare my routes in pure JSX, like RNRF allows me to. Not only it's simpler, it's also cleaner and easier to read. Now I'm not saying that JS is hard to read (since React Navigation routes are declared in pure js), but sometimes when I have a designer or a project manager reviewing something with me it's way faster for me (and less boring to them) to find a route and make changes to it instantly.
• I truly believe that good naming conventions can make everything easier. I personally like the naming conventions on RNRF more than the ones used on React Navigation.
• Although RNRF documentation is not as "complete" as React Navigation, I still love it. The GIF's and examples @aksonov put up hooked me up from the first time I was studying this lib. They also got updated recently and are way better then v3's docs.
• Last but not least, trying new libraries take time. RNRF works flawlessly for me, and therefore I don't see value in trying another routing library without a good reason. Maybe if I ran across a major issue I'd consider jumping to another boat, but for the time being I'm pretty happy with RNRF (thanks @aksonov).

[daviscabral]

Notice: this issue has been closed because it has been inactive for more than 30 days.
You may reopen this issue if it has been closed in error.