Five caveats of React Native

Дмитрий Пацура
LOWL Agency
Published in
7 min readAug 23, 2017

--

Статья на русском: https://medium.com/p/dd7c60386280

At my current workplace our team develops big social network as SPA with usage of React. Most part of the time I work with JavaScript. When I’ve discovered an opportunity to develop mobile applications for iOS/Android using JS, I’ve been amazed by possibility to use one language for different platforms.

Through the last few years I became somewhat experienced developer in this field and I want to share with you some caveats I stumbled upon. It may come in handy knowing them if you’re going to start developing with React Native.

1. Knowing only JS is not enough for a serious project

Most part of development process will include coding in JavaScript, but sometimes you will have to use a native programming language for platform:

Interaction with mobile platform is made via modules written in native language.

Simple example: you want to find a native module for background file downloading (i.e. when application is hidden).

Fetch API in React Native is not enough for this

As a result of my quick research I’ve found a module that supports iOS and Android platforms:

Pull Request in Open Source Community (library maintaining) — something you’ll find yourself doing if you want a working solution

I’ve picked this library because I believe that it’s the best solution, but at the moment library didn’t support multipart/form-data file uploads to the server.

There are two ways to get things done in open source project:

1. Feature request from library developer

In open source community you can spend a lot of time waiting until some enthusiast will implement your requested feature. Probably too long for your company.

2. Write feature and create pull request by yourself (not that hard actually!)

My solution for this problem is spending some time for implementation of desired feature in short period of time. By the way, it’s not that hard to code in Java for Android or Objective-C for iOS:

2. Native components look may differ depending on platform

For example, you want to implement dropdown/select element with the list of languages available.

In React Native documentation you may find a component named Picker, after adding which in your application you may notice a difference in visual representation on different platforms:

Left: iOS, right: Android.

Yet another moment, when I work on GHubber, I needed to display modal with commits, I find component Alert

Left: Android, right: iOS.

You will learn that sometimes there are more than visual differences. Functional too! Android can have only three buttons within Alert component (positive, negative, neutral), but in iOS you can add as many as you want.

3. Application layout != HTML/JSX

In React Native component layout is implemented with philosophy of FlexBox in mind thanks to crossplatform framework Yoga. Component style is close to what you’ve already used to see in web. But, unfortunately, it is not web and you will learn it while developing with React.

4. Native code can fail too :<

There are bugs in any piece of software. So, your top priority is installing a tool for bugs detection. But do not forget about bugs nature: some are related to JavaScript and some are native. In my projects I use Sentry, because:

  1. In it an open source software
  2. There are many different integrations platforms (browser/nodejs/php/android/ios/react-native etc.)
  3. Support of source maps and dsyms
  4. Compatible with Docker. Docker is ❤️

There is an integration for React Native:

Everything about this module installation is pretty simple. Fun fact is that this module can have bugs too :D

If you want to avoid beginners mistakes, I’d like to recommend to follow some simple rules since your very first commit.

  1. Strictly use Flow everywhere
  2. Do unit-testing
  3. Do not forget about existence of ESLinter

5. Do not forget that React Native is young

React Native makes us happy for more than two years. New releases are made monthly. Keep in mind, that new versions may not be backwards compatible with older versions.

Let’s take a look at two last releases at the moment:

0.47 (last release for 1 August, 2k17)

Not every open source module can be up to date with latest version of React Native. Sometimes you have to help them with it:

0.46

Some modules use React Native inner API, which can be changed without any announcement. Best practices suggest to use only public API because it guarantees some sort of stability in newer releases.

If you’re developer of React Native module, use only public API so your code wont be broken after new React Native release.

For example we can take a look at RealmJS module (mobile applications data storage):

After the moment I’ve updated React Native from 0.45 to 0.46, I had to look at this scary screen 😠

If you’re not a developer of native mobile applications you may say “WOW, OMG, Stop it please 😠”

When you’re facing exceptions or segmentation faults, do not waste your time trying to change your code trying to chase a bug. What you have to do is to open XCode/Android Studio and place break points for bug catching

Or you can add try/catch 😜

After a little module source code digging I’ve found out this interface usage (it is some sort of hack which allows to add private methods to the class)

In React Native 0.46 there is no more method executeBlockOnJavascriptThread, however RealmJS tries to use it with this hack (interface RTCBridge):

After reading this commit I figured out maybe I should use ensureOnJavaScriptThreadmethod but since I’m not a core developer of React Native, I’ve asked for advice from Pieter De Baets (core developer of React Native) 😺

GitHub is a social network, do not be afraid of asking for help or an advice in comments/issues. Or ask something directly from a person with @

Thank you very much Pieter De Baets 🍻 🍰

Conclusion

I like React Native very much despite of some existing problems. Do not be afraid of developing with React Native — in the end you will have crossplatform mobile application, 90% of code is written in JavaScript.

P.S. If you’re going to develop a massive application with React Native you’d better have at least one Android (Java) and iOS (Objective-C) developer who can help you in difficult situation when you have problems with bugs, crashes or some another problem which may not be easy to resolve for JavaScript developer without experience in native platform language.

P.P.S. My experience developing open source React Native application: https://github.com/ovr/ghubber

If you have any question or suggestions feel free to write them in the comments, I’ll gladly answer them!

--

--

Дмитрий Пацура
LOWL Agency

Senior Pokemon at Fintier, Go lover, PHP coder, JS ninja, C/C++ debuger, RN officer, Coffe drinker