1. Navigation is… complex
Read this, by yours truly.
3. You don’t break when iOS or Android changes
When you use a library that abstracts over the operating system SDK API, a peculiar thing happens to your codebase: it does not depend on that SDK directly. Surprisingly, this means the following:
- Less stress when facing major iOS releases
- Less breakage and deprecation of APIs
- No need to conform to new or changed language features (i.e. Swift)
- No need to adapt to new tools (i.e. Xcode, Intellij/Gradle)
Effectively, you detach yourself from these concerns completely, and you can take defensive actions on your terms, in your time.
4. Common codebase is really doable
Write once run everywhere? I think history thought us that we all should give up on that one. But for React Native, when you call a component ProfileHeader, it can either be implemented commonly for iOS and Android, or separately, and your code still depends on that directly:
And certainly things like TabBar will be specifically modeled per platform. It is up to you to abstract things in a way that your code will be reusable to as high degree as possible — that’s software engineering, and React Native simply uses React’s compositional model — which means you should be able to do what ever you want to.
5. CSS without the suck
If you’re doing CSS on the Web, this is what you’ll be looking at, on every project (multiply that pain when you’re a team):
- Pick a higher-level language, such as Sass, Less, Stylus, to allow for variables, inheritance, and mixins in existing work
- Set up a build pipeline for that
- Go through a browser-specific prefixing processor to add all the pesky -moz, -webkit etc. prefixes.
- Minify all that
- Fight browser inconsistency for layout and style
Layout is done solely with React Native’s implementation of flexbox, which is arguably one of the most successful layout models a developer can use today. Everything else that exists in CSS was left out, so I say: this is “CSS — the good parts”.
You can dive right into React Native styling without prior knowledge, with React Native Katas.
Clojure is one beautiful language that I like. This means I’ll probably always be on the lookout for Clojurescript on React Native, and apparently, it has relatively vibrant ecosystem.
8. Remote update your codebase, silently
Today, you can use CodePush for free, in order to control remote updates to your app. Fix bugs, deploy new features and content without going through a tiresome appstore process (note that terms of service for Apple do state that you must not remote update features — but YMMV).
9. Wrap native components easily
React Native comes with a bunch of macros on the iOS side and decorators on the Android side to allow you to expose native functionality declaratively. There’s nothing I’ve seen so far that makes it this easy (go take a look at plugin for Cordova/PhoneGap).
Not only that, the entire React Native codebase is dogfooding on these building blocks, so you should feel confident that it works for everything you’ll try.
For simple and aggregate types, such as strings, ints, arrays and dictionaries, this works fine. However, for opaque types such as a binary buffer, it is less than optimal: currently there’s no support for passing binary data back and forth and apparently, it is because of a non-optimal Buffer implementation.
The solution is one of two:
- Keep the original binary at the Native side, and build native wrapper modules to manipulate it through your own set of commands. The downside here is that you will have to do the book keeping in a reliable manner and ensure no binary piece of data is left stale on the device.