Some time ago
Few months ago we publish series about creating applications using ReactJS and related architectures (flux and redux).
Since then we started using also React Native and we think it’s awesome!
The goal of the post
This post is not meant to be yet another tutorial for React Native, because I believe there are already many good ones over the Internet.
I just want to show you the same app as before, implemented in React Native, because I’m really excited about how similar it looks to the web one and how smooth you can do things.
Lets build the app!
package.json
We will install very similar list of dependencies as in we did in the webapp:
We don’t need all the dependencies related to making app universal because there is no such problem in the native app.
Also we don’t need babel stuff defined explicitely, becasue it’s part of React Native dependencies.
Additionally we are free from caring about building and compiling assets – React Native do this for us too – so no need for Webpack too.
index.ios.js
Entry point the whole application is index.ios.js:
We render there our main component – App.
App.js
Let’s create src directory, where we will put all of our source code.
Create also components directory inside, we will store all compontent there.
So let’s add first one – App.js:
It looks very similar as application.js file, we had in the web version. Whole idea is the same – we use the same redux library.
store.js
To make it working we need to add store:
Also – almost the same as in the web version. The only difference is that we can remove all stuff related to making app universal – so store is even simpler.
Routes.js
Except store we need Routes too:
I found react-native-router-flux very convinient to use and again – very similar to react-router that we used in the web app.
SubmissionsContainer.js
Now we can finally define our first container – SubmissionsContainer – which will be responsible for displaying submissions list:
This is the simplest version that you can implement – which looks the most similar to the web version. But you can also use React Native build in component that will be translated to the native list control. See the documentation here.
Other redux stuff
Rest of the redux stuff is exactly the same – create action_creators, reducers, constants and lib folders (as we had before) and put there SubmissionsActionCreator, SubmissionsReducer, ActionTypes and Connection accordingly.
Key feature for me
Apart from developing for two platforms at once, for me, the killer feature is that it’s so easy to do pretty things. The thing I hate while developing pure Objective-C/Swift app is that many things related to the UI (like colors, font sizes, etc) are mixed with application logic.
Of course, you can set some things using Interface Builder but firstly, I’m not a big fan of Interface Builder, secondly, not everything can be set there and it’s just better to have main colors and things like that saved in constants.
React Native uses Flexbox for styling your components. Although not all the features from web flexbox are implemented yet, I love it!
And styles are the last file needed to make our app working:
Run
Now you can open ios/ProjectName.xcodeproj file in the Xcode and run the app!
Platforms supported
For now there is support for iOS and Android.
During developing internal project I noticed that for now iOS is supported better, but if you don’t do too much custom stuff you should be good with Android too.
If you implement app with common controls you should be fine, if you want to do things like drawing custom shapes using native libraries, you need to check Android support before ;]
Differences in native controls between platforms
You probably wonder what if you need to make e. g. Android version little different.
That’s not a problem! You can easily make different components by just adding platform suffix to the file name – e. g. SubmissionsContainer.android.js.
React Native will just render proper one depending on the platform.
Summing up
Implementing React Native is smooth and enjoyable. The only thing you need to keep in mind is that this is a tool for doing front end. If your mobile application needs to perform high load operations it’s not the right tool for you. But if all your high-performance operations happen in your backend and you use the mobile app only as a client, it’s very convenient to use.