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.
How does typescript compare to flow? I'd love to see a comparison with pros n cons. I haven't tried either yet and I'm curious if you have any recommendations re resources to read.
> 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.
"Define your state shape in terms of your domain data and app state, not your UI component tree."
I'm not sure that's what OP is recommending though? In fact, that redux doc seems to me to making an opposite suggestion to the OP -- it seems to be suggesting you should put domain data, app state, and UI state all in the store, but "define your state shape in terms of your domain data and app state, not your UI component tree." OP seems to recommend trying ot keep app state and UI state _out_ of the store if you can.
I think people in practice have a lot of trouble with this, and making it successful, even after experience.
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.
Then we also get the opposite advice, above, _don't_ think about your component architecture when defining state! "Define your state shape in terms of your domain data and app state, not your UI component tree."
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.
Obviously almost every react native app out there is accessing a SQL db over the network, and they work fine. Are you seriously saying that it's slower to get data over the react native bridge than over the internet?
We are using a local database as a mirror for offline use, which is a key requirement. Profiling (a forgotten art nowadays) shows that most time spent during queries is in this bridge and not in the actual queries.
I know realm has a React Native library which I imagine you could use to access the db directly. Can you do something like that with SQLite? I.e access it without going through java/the bridge?
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.
Also very different approach. Flutter renders all graphics much closer to the metal instead of binding to platform's UI APIs so you're effectively shipping the UI toolkit that will be the same on jelly bean and iOS 10 (or different if you want)
Not in particular. I appreciate the suggestion of the official documentation. I do need to rtfm, however after that I will be looking for further examples and explanation. Oh, but if there is any useful tooling I should be aware of that would be quite helpful.
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
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.