What are the main differences between ReactJS and React-Native?
What I’ve learned from building web, then mobile apps with React
React-Native has been around for about 2 years and became a really interesting framework since it can be used for Android and let us build cross-platform mobile apps. A few contributors also customized the framework to build desktop apps for Mac and Windows, which is quite cool.
React-Native is very similar to ReactJS in a way, but there are differences you need to know before you start your first native app. In this article, I’m going through the main differences I have encountered as a ReactJS web developer who learned to use React-Native and built a few native apps with this technology.
Setup and bundling
To run your app, you will need to have Xcode (for iOS, on Mac only) or Android Studio (for Android) installed on your computer. You can either decide to run it on a simulator/emulator of the platform you want to use or directly on your own devices.
DOM and Styling
React-Native doesn’t use HTML to render the app, but provides alternative components that work in a similar way. Those React-Native components map the actual real native iOS or Android UI components that get rendered on the app.
Most components provided can be translated to something similar in HTML, where for example a
View component is similar to a
div tag, and a
Text component is similar to a
Because your code doesn’t get rendered in an HTML page, this also means you won’t be able to reuse any libraries you previously used with ReactJS that renders any kind of HTML, SVG, or Canvas. Although you might find alternative libraries for React-Native, react.parts has a Native category for you to find what you need.
I don’t know about you, but even though Flexbox has been around for quite some time already, I’ve never been completely immersed in its use, mostly because the projects I was involved with required backward compatibility with older browsers. With React-Native, you have no better way to build a nicely responsive app than using Flexbox. It can be tricky at first as it doesn’t always behave as it would do with CSS, but you will become quickly good at it once you got the basic understanding. I would recommend you to read this article to learn more about it: Understanding React Native flexbox layout.
Animations and Gestures
onPanResponderMove (touchmove) or
onPanResponderRelease (touchend). Those functions will give you access to the native event and the gesture state with information like all the touches and their locations as well as accumulated distance, velocity, and the touch origin.
In my opinion, the main difficulty with the PanResponder comes when you have nested views/components with their own PanResponder, and you need to decide which one must be granted the control of the gesture. To learn more about Animated and the PanResponder, this article can be very helpful: React-native Animated API with PanResponder
When I started to build my first mobile app with React-Native, I was wondering how to navigate between 2 scenes. The first thing that I’ve done was to search for an alternative to react-router, this famous library that most React web apps use to transition between pages. I found a few libraries that do similar jobs, but there was always something I didn’t like about the ones I tried: either it was quite complicated to use, I wasn’t satisfied with the animations, wasn’t customizable the way I wanted it to be, or wasn’t behaving or working properly on both Android and iOS devices. Then I started wondering how navigation actually works, and I found the Navigator component provided by React-Native. I should have started from there, looking for an alternative of react-router was in my opinion not the best idea.
Most mobile apps don’t have plenty of scenes going in every direction like would do a web app, the Navigator component even though it might seem a bit complicated to use at first will provide you everything you need to manage the transition between scenes. Unless you build a very large-scale mobile app that requires lots of different scenes and you are afraid to get lost at some point, I think you should stick with Navigator. You can also have a look at NavigatorExperimental, but in my opinion, it’s not ready yet to be used for production.
When you build a Native app, it’s important to know the user interface and experience for iOS and Android might need to be different. This article explains it very well: Designing for both Android and iOS.
On the assumption you have control over how your app will look like and behave, you have two choices:
- You can define a universal design for your app to look exactly the same for both platforms as long as it stays intuitive and doesn’t confuse either platform user.
- You can define sets of code for each platform, meaning you will have a different DOM, stylesheets, and even maybe different logic and animations in order to follow the UI and UX guideline of the platform.
If you decide to go with the second point, React-Native can detect which platform you are running the code from and load the right code for the right platform. I would recommend you to have the main logic of your components defined in one file called index.js, then you’ll have the presentational components defined with individual files. For iOS and Android, you will have respectively index.ios.js and index.android.js files.
If you organize your folder structure following my recommendation, it will look like this:
If you feel like having 2 different files is too much overhead for very minimal changes you can use the Platform module with a conditional statement.
When you start a new native project, you get a few developer tools out of the box from React without the need of installing anything, and that’s pretty awesome in my opinion. Hot Reloading is available and is great to use when you need to make small changes to the styles of your app. For bigger changes impacting the logic of the app, I usually prefer to use Live Reload which reloads your app entirely as you make a change in the code.
The beauty of working with React-Native is also the ability to use most developer tools you use with ReactJS. Chrome Dev Tools works beautifully to inspect the network requests (although you need to add a little trick to see the requests), display the console logs, and stop the code on
debuggerstatements. You can even use the great Redux DevTools to inspect the state of your Redux store. One feature that I miss the most though is the ability to inspect the DOM as you would do on the web, the native Inspector is definitely not as good.
If you develop an app for both iOS and Android, you will need to learn how Xcode and Android Studio work in order to make sure everything is set up properly before the first deployment of your app on the App Store or the Google Play. For iOS, it works just like you will deploy a regular native app, although, for Android, you will need to follow the React recommendation to sign your APK before uploading it to Google Play.
If you miss the ability to simply type a single command line to publish an update of your native app like you would do it with a web app and a VCS properly setup, you can use the awesome Code Push to deploy code directly to the user, without the need of archiving, sending your app to the store and waiting for it to be ready. Code Push is great if you want to make a few improvements or bug fixes but is not recommended if you want to add entirely new features.
The community around React-Native gets very big and keeps growing, the technology is not going away any time soon and I would definitely recommend any web developer who wants to create a mobile app to forget about Cordova and give it a try.
More articles from me
- How to better organize your React applications?
- Level up your career as a React Developer
- What React global state management libraries should you use?
I recently started to use Twitter, you can follow me here: @alexmngn
Enjoying my writing? Show some love and donate here!