React and React Native have been out for awhile now. They are here to stay and have been a total game changer. If you look at this blog post on StackOverflow about the job trends for this year, it confirms that knowing React is a must if you want to keep up with current tech trends and best practices. This is why I decided to learn React, and, because most of the things I’ve been doing for the last 3 years are mobile apps, I decided to go with React Native.

I’ve been doing software for almost 9 years now. This is not the first time I’ve had to onboard a new technology/framework/you name it. Every time I’m about to start a process like this a little voice inside my head begs me: “Please, not another TODO app, please”. This is why I decided to do something a little bit different this time. I thought: “Let’s learn React Native doing something fun! Something that actually involves some sort of real use cases or things that I could be implementing on my first/next React Native app.”

What are we building?

In this blog post, we are going to build “Gorillagram”, our own kind of Instagram app. We are going to use Cloudinary as our CDN Cloud Service to store and retrieve the images (I encourage you to check their services, they are really great and it could be very useful in your next projects).

Our app is going to let users post images, tag them (at least one tag will be required), attach the location where the image was taken (this will be optional) and then search images by tag.

Also, on the React Native side, we are going to be covering/implementing things like:

Redux

Navigation (with Redux)

Pulling data as well as posting data to Cloudinary

Applying customizations per platform

Geolocation and maps

Working with the photo gallery and the camera

Supporting different languages in the app

The current version of the code is here. Feel free to clone it, fork it or even send pull requests! There you will also find some useful tips and information. Now, let’s start the journey!

Redux

React alone only covers the view layer of the app, so you need to figure out a way to support your workflows and your logic. That’s where Redux comes into play as a convenient state container. If you are used to working with things like MVC or MVVM, you will find that Redux is a little bit different.

Basically Redux handles a state. Its scope is the whole application and it wraps all your data. This state is handled by a global store. You can then start to create your components and bind them to the parts of the state that concern it. Finally, there are ‘actions’ that could change the state, and as a side effect of this, update your view components. One last important concept in Redux are ‘reducers’, which are small functions to generate a new state piece given a data input (usually provided as the result of an action).

I like to think about Redux as a pattern based on the “cause and effect” principle. The actions are the cause of a state change, and therefore, a change on the view.

To start implementing Redux, we are going to include the libraries (via npm):

redux

react-redux

redux-logger

redux-thunk

Defining the actions

The first thing I like to do is to define a module with all the available actions into the app. This way we can store and reference all actions on and from one single place. The app/actions/types.js file looks like this:

This code snippet calls the Cloudinary API to fetch images given a tag and, once the result is back, it dispatches the SET_SEARCHED_IMAGES with the found images data.

Reducers

In Redux, once an action is dispatched, reducers handles the action, “transform” the received input and, finally, produces a new piece of the state. This step “refreshes” the state and, as a side effect, React updates all the components that are bound to the specific piece of the state which has been changed. You can find the reducer which is in charge of the images in the app/reducers/images.js:

Navigation (with Redux)

Navigation has been one of the most discussed topics on React Native since day one. There are several libraries trying to solve the problem. After digging around, I found react-navigation library works best for our purposes, especially because it includes a stack implementation and supports integration with Redux out of the box.

Remember when we created our Redux provider in our index.js files? Right under it, we are going to place our NavigationContainer component, which is basically a wrapper of the StackNavigator provided by the library. We are wrapping the StackNavigator and not using it directly, just to support a couple of features that I will explain in more depth later. Our NavigationContainer component will look something like this:

At this point the most important thing to explain is how to create the AppNavigator component using the helpers also provided by the library. This helper allows us to propagate the dispatch function and the navigation state to all the inner views that we are going to be creating and stacking as long as the user navigates into the app.

This way you will be able to navigate from one view to another. Let’s use the navigation from our Home view to our ImageEditor view as an example. In our app/views/Home.js file you will find this code which allows us support the navigation:

The navigation component is attached to our views props because the library supports this. The only thing we need to do to get this working is to create reducers to handle ‘push’ and ‘pop’ actions. Check our app/reducers/nav.js file:

Android back button support

As you might notice, our NavigationContainer implementation actually uses a NavigationContainerBase component which abstracts pretty much everything we need. But, it also gives us space to create platform specific containers which are going to inherit from this base.

When it’s about navigation this is very helpful because we are going to be using the app/containers/navigation/NavigationContainer.android.js component to expand our initial implementation for Android devices and adding support to the native back button.

We are adding a listener to the hardware back button and just checking if there are stacked views when the user hits it. If there are stacked views, we just fire a goBack action to go back to the previous view and return true to let React Native know the event was handled by us. If there are no stacked views, we just return false to not handle the event and bubble it to the device itself. Our code looks like this:

Customizations per platform

There are two ways to apply customizations per platform in React Native. The first one is using the Platform module which lets you detect the current platform and apply customizations explicitly; like this:

The second way (which I prefer) is using a pattern of file names including the platform you want to customize. Here we are going to use our NavigationComponent as an example. As you may know, iOS devices don’t isolate their native top status bar from the whole viewport you have available to use when you are building your apps. This status bar has a height of 20px and there is a big chance you have to arrange the top of your app by setting a margin top yourself. This applies only to iOS, not to Android, so, here we are requiring custom code for iOS.

(NOTE: there are newer features and implementations regarding status bars for both platforms so there is a chance that you will need more complex code to deal with status bars in the future)

Lets see our code. If you go back to our code base, you will find that we have a app/containers/navigation/NavigationContainerBase.js file and you can see its code looks like this:

The virtual tag on a function or a property is a hint which means it can be overriden by any child class. Following our example, in the app/containers/navigation/NavigationContainer.ios.js file you will find this:

In this child class, we are using the file extension pattern supported by React Native out of the box to apply customizations for iOS devices, in this case, a margin-top of 20 to the main app view wrapper. The Android version doesn’t override this function so it keeps the default margin-top of zero.

Maps

As the official React Native documentation states, when it is about maps the best thing you can do is to use the component built by Airbnb. If you have previous experience working with maps using javascript libraries, you will find this component very easy to use as it keeps several similarities with the work we have done before with maps on web and hybrid ecosystems.

Working with the photo gallery and camera

Our implementation of the interaction with both photo gallery and camera relies on these two libraries:

react-native-actionsheet

react-native-image-picker

First we are going to use react-native-actionsheet to let the user to select what kind of source he/she wants to use to upload a new image: photo gallery or camera.

The configuration of the action sheet in the app/views/Home.js file looks like this:

ref={(o) => this.addImageActionSheet = o}: we are saving a reference of the action sheet itself which is going to let us to show it later by doing this:

onAddImage() {
this.addImageActionSheet.show();
}

options={this.props.language.home.addImageOptions}: options config expects an array of strings but since our app is localized we reference the current languages config (we are going to explain this deeper in the next section)

With the action sheet in place, it’s time to use react-native-image-picker to pick an image from the photo gallery or trigger the camera to take a new image from scratch. Based on the user selection we are going to be calling launchImageLibrary or launchCamera provided by the library. At the end, both functions will be returning the same result: the base 64 representation of the image and that’s what we are going to be posting to Cloudinary.

This view is the place where the user will be able to input some extra data regarding the picture like tags (at least one required), a caption, and the location where the picture was taken (optional). It looks like this:

Supporting different languages in the app

There is a big chance your user base will be composed of different cultures. That’s why supporting different languages in your app could be a key functional requirement.

The first thing we are going to do is to create a module for each language we want to support. In this case, Gorillgram supports two languages: English and Spanish. Our English module in app/config/languages/en-US.js looks like this (The Spanish module has exactly the same structure but uses a different set of translations):

Once we have all the modules matching each language we want to support, we create a new module at app/config/languages/index.js to export all our languages as a collection (this will make our code changing languages very easy):

With the configuration in place, now we need to include our language support into the “Redux scope”. The first thing to do is to add the current language to the store. This will be done by creating a reducer, which is going to let us eventually “transform” our state. Check app/reducers/app.js:

Next, we create an action which is going to let us set the language. It’s worth mentioning that this action will persist the language id to reuse it when the user comes back to the app later. Check app/actions/app.js:

To fire this action and actually change the language, we’ve created a Settings component in app/components/Settings.js, where again you will find an action sheet showing all the available languages and once the user picks one, the action will be fired.

And finally, you can start to create your components and bind the texts to specific parts of the language configuration. Let’s use our Feed component located in app/components/feed/index.js as an example, specifically the text we show when there are no images to display in the feed.

Loading the user preferred language on every app start

The last thing we need to do is to check if the user uses a language different than the default. Remember: we persist the selected language id every time the user changes it. To achieve this we only need to read this setting, search for the set of translations and, once we have it, dispatch the action to set the language. This refreshes all our components showing localized texts. Check again our store in app/store.js:

Final thoughts

The benefits of being able to deliver real native experiences to our users are huge. The sensation of being “out” of the HTML5 paradigm, without totally quitting to javascript, is very refreshing.

I encourage you to start playing with React Native if you haven’t. I’m pretty sure it will be the next best way to create mobile apps, if it isn’t already. Now go start coding and share your experiences below!

Diego is a full stack developer with more than 9 years of experience with most of it in .NET technologies and Javascript.
In his free time, he enjoys dogs, football, basketball, pizza, tattoos, drums, family, friends, Thai and Chinese food, concerts,
jokes, Twitter, memes, and technology. His social links are:
Twitter: https://twitter.com/ninja_gaiden,
LinkedIn: https://www.linkedin.com/in/diego-garc%C3%ADa-93184b83/,
GitHub: https://github.com/ElNinjaGaiden,
Personal website: http://diegogarcias.com/,
SkypeId: diego.garcia.segura