React Native: developing using best practices (Part 1)

React Native has been around for two years and when it was introduced, made a huge buzz among developers. This all happened because it lets developers write JavaScript code and generates apps for the two major mobile platforms (iOS and Android) that have the look and feel of a native app. To be honest React Native apps have nothing to envy to all those apps that have been created using Objective-C/Swift or Java. This is because JavaScript communicates with native components of each platform, through the so-called “bridge” so parts of code that have to do with UI are compiled into the fundamental UI building blocks of iOS and Android. We have no “weird” hybrid environments, no embedded Webviews, no poor performance. Isn’t that awesome?

Although it’s an immature technology (has not even reached version 1.0 yet!) a great community has been grown around it. A lot of libraries has been developed and open sourced in a short period of time. Also plenty of people that really like this new tool have published many great articles on how to write quality code for React Native framework. I am one of those who felt in love at first sight with it, so I will try to find out the best practices that should be applied to a React Native project in order to have an understandable, easily maintainable and scalable, and highly performant mobile app.

Don’t even think about not using Redux

About a year ago, I started playing around with React Native, I used to search a lot about its ecosystem, technologies and libraries that have been developed around it. One of the most popular search results (maybe the most popular one) that was coming up frequently was the term “React + Redux”. This one really intrigued me and wanted to find out what this technology is about. After spending a few hours on its website and reading about the most important parts of it, I thought I had grasped the concept of it. When I was done with reading I had a very simple question for myself. “OK, all this looks kind of interesting, I should definitely give it a go at some point, however, why should I use it and how this new technology is gonna take my React Native apps to the next level?”

What’s Redux?

As its documentation states, redux is a predictable state container for JavaScript applications. It’s both regular library and a data-flow architecture. A lot of people think that it comes with React Native and it is just another tool of it. That’s a big misunderstanding! It’s a framework-agnostic tool that fits with React Native really well but it still can be used with almost any JavaScript library or framework like jQuery, Angular, Ember, Meteor or even vanilla JavaScript.

Why should I use it?

React does not consider direct component-to-component communication as a good practice even if it has the ability to support it. An architecture like this, is going to lead to a poorly structured source code sooner or later which will be difficult to maintain and scale. Redux offers a way to store all of the application state in just one place with global scope. Then your React Native components dispatch actions that trigger changes to the store. Components that need to “know” about those changes should be connected to Redux state.

Redux store can be considered as an intermediate between our data and UI. So there is no communication between components. Everything should go through Redux state first. This simplifies data flow a lot and actually makes our life much easier when we have to do with data.

What’s the pros of Redux?

A lot of benefits arising from the use of an architecture like this. Here are the most noticeable.

• Result predictability. The source of truth is one and only and it’s called Redux state! All “global data” of our application are stored in there and any change that has to do with those data takes place there as well.
• Absolute separation of UI and data. React itself states that we should develop applications in such way that data are separated from UI elements. This concept is elevated by the use of Redux as the state is its concern and UI is React’s concern.
• Clean and organized code. Easy to predict outcomes and a severe structure conduce to non-spaghetti and clean code.
• Forget re-rendering. Data and UI components are two different entities. Components will render only when the part of the state that is linked to them is changed. This noticeably improves performance and make us forget about the process of re-rendering once and for all.

Write reusable components

React recommends creating as many tiny components as we can. This makes the whole application easier to navigate, much more well-structured and let us find bugs and fix them way much quicker. When you build a screen (which is actually a bunch of components) you better have in mind that you should break down common UI elements (like buttons, lists, forms etc.) into reusable block of codes that will let you repeat yourself again and again and minimize work when building other screens of the app in future. This way of writing code will generate many stateless components. To be honest, that’s our goal!

But what that actually means?

Let’s say we have a screen which includes several components and one of them is a button. When this particular button is pressed, triggers a change to Redux store. Some people would handle this, connecting this button to Redux and dispatching actions from there.

This component is able to trigger a change to Redux state, however, is it reusable enough? If we would like to reuse it at a later stage, would we be able to do it? The answer is NO! This particular component is not reusable at all. We can’t use it in another screen where for example it should navigate you to another screen. You should create an identical component instead which is not a good practice as you gonna repeat yourself once again.

To solve this and make your button fully reusable you should just let its parent know that this button is pressed and after that parent dispatches the action. So now we have a 100% reusable, “dumb”, stateless component (they are officially called Presentational components) that call callback props on user interaction and can be used anywhere in your app.

Here is the code of screen and above it you can see the code of the component.

Also, when you develop a React Native app you will probably realize that a lot of the screens that are going to be built have plenty of similarities to each other, like similar header, margins/paddings, outer borders, etc. Instead of writing the same elements, styles and functions again and again you can just create a wrapper component, apply all this in there and use the { this.props.children } command. Whatever is wrapped around this component is able to share the same styles and functionalities.

Extract as much as you can

Usually, React Native projects includes a large number of common elements such as styles (colors, font sizes, etc.), images, global functions (functions that format dates and times, make requests to a server) and other (navigation options, static data structures). All those are better to be kept separated from the component code so they can be shared from anywhere in your app. I usually prefer to have a folder called common and put all those things in there so I can use them whenever I want in any component of my app. In this way, you keep all common functions and variables away from your component code. This fact makes your codebase cleaner. It’s also way much easier to maintain and scale it and keeps your app well-structured.

Below is an example of my color.js file which includes both common variables and functions.

That’s was the first part of “React Native: Developing using best practices” series. A second part with more best practices will follow soon.

Hit the ♥️ to spread the word!