10 Things you should know about React Native

Posted on 2016-06-20

If you’re just starting out, you probably have a ton of questions. Hopefully these pointers give you some confidence to go and try React Native today.#### 1. Navigation is… complex

Read this, by yours truly.

2. Redux and probably most Javascript libraries you know work flawlessly

The surface area of React Native’s API is amazing. It stands out of your way when you want to adopt components from the React ecosystem such as Redux, Immutablejs or vanilla Javascript libraries like lodash or moment.

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:

<View>
  <ProfileHeader/>
  <Settings>
{
  settings.map((k,v)=>(
    <View>
      <Label>{k}</Label>
      <Value>{v}</Value>
    </View>))
}
  </Settings>
  <TabBar>
    <Item>A</Item>
    <Item>B</Item>
  </TabBar>
</View>

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

React Native picks Javascript as the styling language. With this you’re getting variables, inheritance, mixins, and really anything you might imagine. And, since that’s code, you don’t need to minify it.

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 KatasReact Native Katas#### 6. Use any language that eventually compiles to javascript

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.

So what ever flavor you choose as long as it compiles to Javascript is valid. Just remember, being a cutting edge technology, you’ll always get the best experience using what ever React Native already comes with.

7. Avoid Javascript fatigue

Which brings me to this point: using React Native, you get to have a first-class modern Javascript experience without tiresome configuration of your build pipeline. Everywhere you’ll look, you’ll feel that developers come first; it’s already awesome by default.

8. Remote update your codebase, silently

Since your app is usually a slim native layer and a thick Javascript bundle, it is easy to be able to control how that Javascript bundle is maintained on and off the device’s storage.

In your development workflow, things are already being served over the wire (that includes the Javascript bundle and hot updates), so React Native sort of falls into a use case for remote updates.

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.

10. You can’t handle binary data in Javascript just yet

React Native uses a bridge; a transport mechanism to pass messages such as “Call this native function with these parameters (Javascript to Native)” or “Here’s your event (Native to Javascript)” back and forth from Javascript and native domains.

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:

Encode binary data as base64 and from there, you’re handling a string. This is how many, if not all of the component that pass typical binary data to the Javascript side work.
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.