Coming from a background of WebViews hybrid development (Cordova/Ionic), React Native simply blew my mind. How I see it is you get the UI advantages of doing native development, with the advantages of using React for the front-end just like I would for the web and going the native way whenever you need to.
I don't think all projects should be done with it as native development still has its place for certain kind of apps, but for a typical thin-client app wrapping a web service, it's really great.
I'm going through a similar experience. I have some experience with Objective C and iOS, almost nothing with Android and I have good experience with (non-mobile) Java. Basically I have a week to build Android app which should be quickly ported to iOS. So far my experience is mixed. React Native feels like very powerful tech. But standard library is very minimal, tooling looks very fragile (it works, but I'm very afraid of the moment when those thousand node-gradle scripts will break), things like navigation look very complicated (I investigated react-navigation, had quick glance over other solutions and finally decided to roll my own tiny navigation and animated menu). Modern JavaScript is OK, I guess, though it's so far from proper typed language with proper tooling like Java.
What I wish to exist is something like Kotlin with react-native like library, with single good cross-platform library of components and good solid tooling.
Facebook developers are awesome, but they are paid for Facebook apps, not for making good library, IMO, good library is just a by-product which they kindly shared and it feels everywhere.
Overall I think React Native is the best cross-platform solution out there. It doesn't carry overhead of bundled HTML webview, its view is advanced enough for complex GUI, it provides smooth animations and React is something very interesting actually. Also you can push updates without app-store approvals, if I got that right (I'm not sure about Apple). For apps built in haste with multiple bug-fixes every hours it's important.
Navigation is indeed a hairy beast right now. We're working hard to get React-navigation in shape for 1.0. I think the solutions from Wix and Airbnb are fantastic -- but the community deserves a really polished, JS-only solution that's ready for production. I hope you take another look at React-Nav when we release 1.0!
Disclaimer: I work on React Native, react-navigation, etc @ Expo (expo.io)
I recommend https://github.com/wix/react-native-navigation for now, the docs is well done and makes it easier to integrate with. The UI part is implemented natively, but you interact with it on the JavaScript side.
AirBnB just started working on one too that seems promising, but it's not ready for primetime yet.
>But all of this doesn’t come without a price for someone that, like me, is a heavy user of the ctrl+space code completion features of both Xcode and Android Studio.
What about using Visual Studio Code with the compiler set on 'checkJs'? I've just started using TypeScript and I don't think I can ever go back to raw JS.
Same. I evangelize TypeScript whenever I can. I don't think I'll ever be as efficient in JavaScript as I am in TypeScript, now that I've tried it. Granted, it has its quirks, but (especially when writing React) it's invaluable to me.
> Next, plan your Redux store ahead. I feel like I made the mistake of overusing it. Almost every property of my app is managed by Redux and this results in large reducers and many many actions to control all that. It’s very important to figure if some prop will be needed outside a certain component or not and, if not, keep that inside that component.
How can you possibly know _in advance_ if a prop will be needed outside a certain component (you haven't written yet) or not? This seems to imply a suggestion to completely architect the entire app (what components exist, how they relate) before you write much code. And then somehow being correct, even as you develop the app and add new features etc.
I haven't done anything with React Native, and am only a beginner at web React, but this kind of data management architecture has definitely been one of my biggest challenges. I find it hard to change things once they're there, but hard to know what should be there up front.
>>> How can you possibly know _in advance_ if a prop will be needed outside a certain component (you haven't written yet) or not? This seems to imply a suggestion to completely architect the entire app (what components exist, how they relate) before you write much code. And then somehow being correct, even as you develop the app and add new features etc.
In engineering, that's what we call the design phase.
1. Define your state shape in terms of your domain data and app state, not your UI component tree.
2. Your reducers do not need to have a 1 to 1 mapping to actions. If you need to fire multiple actions to change the data you need then rethink your reducers.
You can make that effort of thinking the component architecture ahead and that will definitely help. To be honest I was thinking more about props that you'll know will live inside a component but end up on the redux store anyway. I made this mistake with forms on my first react native app by having any field value on the store. I didn't really need to that and the store got bigger and bigger because of that first choice.
Well regarding IDE's i'd say try WebStorm (by JetBrains).
It has the best React support ever since React existed, and every IDE feature imaginable. And also, its basically the same IDE as Android Studio, so a very small step for a App programmer.
Great post. We have been building our native apps on React Native for about half a year now and it has been awesome. Completely agree with this whole article.
Related: I would highly recommend trying out/using Expo.io if you are new to React Native and just want to get something working incredibly fast/easy to "hack" around with. It's a fantastic wrapper around React Native to jumpstart the whole dev experience.
I have been working on a large React Native project for several months now. It's great for quick prototyping but once we started doing heavy database stuff it got really slow, especially on Android. Of course we could have ported that part to native code, but that kind of defeats the purpose, doesn't it?
Assuming you don't do heavy work in the UI-loop: I find react-native's bridge memory-management on Android rather questionable: [0]
They make heavy use of structures in native memory for argument-passing between JavaScript and Java. Once again someone thought they could outperform the JVM with their C-skills. My critique was dismissed :-/
Even though I showed that giving up RN's native memory and just sending serialised Json-Strings on the Heap over the bridge is 50-100% faster (and doesn't interfere with GC, so it should have less lags as well): [1]
The image library they use, Fresco, does the same. There are many year-old bug-reports open regarding OutOfMemory-errors and crashes, and RN apps tend to get unstable with more images. My bug-report [2] was dismissed as well without proper explanation.
But: At least some guy or girl didn't have to give their custom code up for to the better JVM. scnr
I use Strings for arguments in production and it's faster, so maybe try that out. :)
It doesn't defeat the purpose entirely in my opinion. Even if you write that core native code and use RN for the rest of the app, those elements will be potentially easier to ship and maintain.
I'd like to see the feedback on this as well. It seems very promising but I wonder what the real-world performance and dev/build/release experience is like.
Why trust this framework when it can't even get a simple iOS navigation bar right. At one point you need to at least write a "bridge" in Swift or Java because RN did not cover even over 50% of the SDK.
Still happy with Jquery-mobile , is Easy ,OOP and Better.
React.js is a lost of time as many other framework that try to copy the javaBean concept.
When browser support completly ES6 all this framework will be forgotten
[+] [-] hamstercat|8 years ago|reply
I don't think all projects should be done with it as native development still has its place for certain kind of apps, but for a typical thin-client app wrapping a web service, it's really great.
[+] [-] weaksauce|8 years ago|reply
[+] [-] vbezhenar|8 years ago|reply
What I wish to exist is something like Kotlin with react-native like library, with single good cross-platform library of components and good solid tooling.
Facebook developers are awesome, but they are paid for Facebook apps, not for making good library, IMO, good library is just a by-product which they kindly shared and it feels everywhere.
Overall I think React Native is the best cross-platform solution out there. It doesn't carry overhead of bundled HTML webview, its view is advanced enough for complex GUI, it provides smooth animations and React is something very interesting actually. Also you can push updates without app-store approvals, if I got that right (I'm not sure about Apple). For apps built in haste with multiple bug-fixes every hours it's important.
[+] [-] skevy|8 years ago|reply
Disclaimer: I work on React Native, react-navigation, etc @ Expo (expo.io)
[+] [-] hamstercat|8 years ago|reply
AirBnB just started working on one too that seems promising, but it's not ready for primetime yet.
[+] [-] zengid|8 years ago|reply
What about using Visual Studio Code with the compiler set on 'checkJs'? I've just started using TypeScript and I don't think I can ever go back to raw JS.
[+] [-] roboguy12|8 years ago|reply
[+] [-] ssijak|8 years ago|reply
[+] [-] jrochkind1|8 years ago|reply
How can you possibly know _in advance_ if a prop will be needed outside a certain component (you haven't written yet) or not? This seems to imply a suggestion to completely architect the entire app (what components exist, how they relate) before you write much code. And then somehow being correct, even as you develop the app and add new features etc.
I haven't done anything with React Native, and am only a beginner at web React, but this kind of data management architecture has definitely been one of my biggest challenges. I find it hard to change things once they're there, but hard to know what should be there up front.
[+] [-] user5994461|8 years ago|reply
In engineering, that's what we call the design phase.
[+] [-] djtriptych|8 years ago|reply
[+] [-] RubenSandwich|8 years ago|reply
http://redux.js.org/docs/recipes/reducers/BasicReducerStruct....
Here are a few gotchas to avoid:
1. Define your state shape in terms of your domain data and app state, not your UI component tree.
2. Your reducers do not need to have a 1 to 1 mapping to actions. If you need to fire multiple actions to change the data you need then rethink your reducers.
[+] [-] swsieber|8 years ago|reply
[+] [-] ruimagalhaes|8 years ago|reply
[+] [-] barrystaes|8 years ago|reply
It has the best React support ever since React existed, and every IDE feature imaginable. And also, its basically the same IDE as Android Studio, so a very small step for a App programmer.
[+] [-] bluetidepro|8 years ago|reply
Related: I would highly recommend trying out/using Expo.io if you are new to React Native and just want to get something working incredibly fast/easy to "hack" around with. It's a fantastic wrapper around React Native to jumpstart the whole dev experience.
[+] [-] thedjinn|8 years ago|reply
[+] [-] cel1ne|8 years ago|reply
They make heavy use of structures in native memory for argument-passing between JavaScript and Java. Once again someone thought they could outperform the JVM with their C-skills. My critique was dismissed :-/
Even though I showed that giving up RN's native memory and just sending serialised Json-Strings on the Heap over the bridge is 50-100% faster (and doesn't interfere with GC, so it should have less lags as well): [1]
The image library they use, Fresco, does the same. There are many year-old bug-reports open regarding OutOfMemory-errors and crashes, and RN apps tend to get unstable with more images. My bug-report [2] was dismissed as well without proper explanation.
But: At least some guy or girl didn't have to give their custom code up for to the better JVM. scnr
I use Strings for arguments in production and it's faster, so maybe try that out. :)
[0] https://github.com/facebook/react-native/issues/8780
[1] https://github.com/facebook/react-native/issues/10504
[2] https://github.com/facebook/fresco/issues/1363
[+] [-] ruimagalhaes|8 years ago|reply
[+] [-] tootie|8 years ago|reply
[+] [-] htormey|8 years ago|reply
[+] [-] dbbk|8 years ago|reply
[+] [-] coverband|8 years ago|reply
[+] [-] dirtylowprofile|8 years ago|reply
[+] [-] wehadfun|8 years ago|reply
[+] [-] gman83|8 years ago|reply
[+] [-] menckenjr|8 years ago|reply
[+] [-] sethrin|8 years ago|reply
[+] [-] max23_|8 years ago|reply
The official documentation is a good place to start.
[+] [-] code_chimp|8 years ago|reply
[+] [-] aocvr|8 years ago|reply
[+] [-] htormey|8 years ago|reply
[+] [-] ms7|8 years ago|reply
Judging from the table of contents, it seems the book gets into more depth than what else is out there.
[+] [-] mal34|8 years ago|reply
[+] [-] gjjrfcbugxbhf|8 years ago|reply