Why React Native Part Eight

What if I need a native feature React-Native doesn’t support?

If you’re still with me after seven parts, you’re probably thinking this is either too good to be true, or that there must be a catch. I thought the same thing a year ago. But, there really isn’t a catch. That said, there are new and different things to consider when you’re writing your React Native apps. Both the biggest advantage and drawback of React-Native is the native bridge.

I talked last week about how the React Native engine (really the JavaScript engine native to each platform) runs all your JavaScript code and can interpret that into native as needed. Well, what that does is make those native calls a “bridge” from the JavaScript engine to the native code. This is a layer of code (written in C++) that passes data back and forth between the two. Developers can have full access to this bridge from either side with just a tiny bit of work. Simply put, if you want to expose native code to the JavaScript side, you annotate it to say so, and from that point on, it’s available to be called from the JavaScript side. It really is that easy. Of course, there are some restrictions on what you pass, but if you think of it like a really fast remote procedure call then most of those restrictions should make sense.

Another way to think about it is that the JavaScript engine, is running in a virtual computer inside the native code. When they want to communicate with each other they need to send messages back and forth using the bridge, which you can think of as a tiny network. This is how you can expose any native feature you need without waiting for the React Native framework to add it for you.

The bridge allows for basic function calls with objects and simple data types as parameters and return values. This is great if you need to do some intense processing on the faster native side of the bridge and only need the results on the React Native side. And, perhaps one of the most powerful features, is that you can return a view from the native side. That view renders natively and can even be interacted with natively, but it can also be presented and manipulated via JavaScript. Of course, any code you have on the native side needs to be written twice, once for iOS and once for Android. But, once you have your custom native code up and running, you can close your native editor and go back to your single JavaScript code base.

In practice this is a rather rare thing to have to do. Nearly everything you need to do already has modules that handle this for you and React Native tools handle installing the iOS and Android components of those modules as well. But, it’s there and easy to use when you need.

It doesn’t take much to be convinced of this. What sold me was when I saw a React Native component working for both iOS and Android using the native augmented reality SDKs two days after they were announced.

Of course, there may be times when React Native may not be the right tool for the job. Next week we’re going to end the series with a list of things to consider when choosing React Native.