A Q&A with Senior Developer Bertrand Karerangabo
React Native moves JavaScript mobile application development from being simply hybrid, towards a radical fusion of mobile native and hybrid JavaScript development. A powerful omnichannel strategy of learn once, apply everywhere, has made it the choice for many of our mobile apps. You can watch this webinar video to see why we think React Native is better than Native for your next mobile app, and decide for yourself after reading some of the answers in this post. Still have questions? Leave us a comment and we'll be sure to answer it!
1. Can I use React Native along with other JavaScript libraries such as Redux, Lodash, etc…
Yes. You can use all client-side libraries as long as they don't depend on the DOM. You can use all Node libraries as long as they don't depend on the Node core API. Key web APIs are polyfilled and available to go. One exception is localstorage because it is not supported, but you can just mock or proxy it if you have to. You do get AsyncStorage, so you could use that instead.
2. What, if any, are the limitations to Mobile App Development in React Native?
In my view, the biggest limitation of React Native is that it's an abstraction. Abstraction may also be its biggest strength. Where it fails you is where any abstraction is bound to fail you. If your top priority is performance, you'll still find yourself dropping in and writing Objective-C (or Swift/Java). For example, since React Native on iOS is based on UIKit, this might happen every time you need to use CALayer/Core Graphics. If you're doing something unique, like using a niche 3rd-party iOS SDK, odds are you're going to need to wrap it yourself.
In some ways, the abstraction is too light. This means you can find yourself in a place where you're too aware of the underlying native stuff. Native controls will behave like native controls and there is nothing you can do about it in JS-land. Custom native controls will need custom code (plugins or homemade). In some other ways, the abstraction is too thick and complex. Debugging exceptions and errors through the JS bridge is an interesting experience. Knowing Apple's framework in-and-out may not be enough. You may need to know how the pieces of React Native work, like the executor or the UI view manager. Diving into the React Native core can be a daunting task if you’ve never done native mobile app development.
Native is always there so there is nothing you can't do. It's just a matter of time and money. It's easy to draw parallels here to C code with inline assembly. If you need to be on the edge, there's an escape hatch. Just don't be surprised when you start bleeding a little.
Before I scare you off, I should mention that React Native's performance out-of-the-box is phenomenal. Most people in the world write slower native code than what the React Native team has done. An old benchmark I was shown in the early days only started dropping frames (< 60) after a ridiculous number of scrolling UIViews. This is nothing 99% of mobile apps apps will ever approach. All popular custom native controls I could think of were available on npm. The rest of the time you can just build them using JS and CSS. React Native is also surprisingly stable. To date, only 216 issues have been opened with the word "crash". Of those, only 47 were related to React Native (including the CLI). The only crashes anybody is likely to encounter are in JS-land. React Native has obvious limitations but they are not surprising.
TL;DR: If you're doing something where you would have to routinely escape UIKit, then React Native probably can't help you.
3. Other than mobile apps, can I also build games in React Native?
Yes, you could. OpenGL performs like a dream. You can definitely build games. Some cool ones with UIView + Animations, too. The problem is that you may not want to, especially if you already depend on a large mainstream game SDK. The same can probably be said for intensive video editing apps. See TLDR above.
4. What are the tools/libraries that enable us to use React Native mobile apps with a FLUXy architecture?
The same ones you use today. You can (should?) just use redux. You can even use react-redux (3.x until this issue is closed). You may not be able to bring over your react-router/redux-router but that's not really a loss. If you can't live with it, you can track this issue.
My humble suggestion, though, is don't. You can handle the view change request (or subview or w/e) in your state, and use the native navigator as a controller using the requested state to transition screens using explicit actions. You could even implement pre-fetching with a single reducer and progressive loading for expensive network stuff. This even allows you to use gestures to interrupt route changes. All this without odd and opaque abstractions.
Familiar alternatives also exist, like this one.
5. Can we extend React Native by writing our own libraries for it? If yes, then how?
Yes. With magic, normal React...and a bit of native code.
Do you have questions about React Native? Leave us a comment below and we'll be sure to answer it!
So, in short, you should probably use or strongly consider using React Native for your next mobile application.