By now you have probably heard about React Native and how this framework allows you as a developer to create native applications mainly for iOS and Android. This publication aims to be a guide both for people who already develop for RN and for those who are just beginning to take their first steps developing apps with RN.
Although there are several ways to create a project from scratch, the two most common tools for this purpose are react-native cli and expo-cli. And this brings us to the first most common question, which one should I use?
You could say that Expo is the best way to get started as a beginner and although it has come a long way since its appearance so far, it is not without the limitation that, when you need to make use of a native iOS or Android module that is not supported by the creators of Expo you have to eject the project, which means doing it as if you had started it with the react-native cli with the difference of making the process a little more complicated.
Expo is good if you want a quick playground to test code snippets that would later be integrated into a full react-native cli app, but if what you really want is to learn mobile development, Expo is not the tool you should use.
For that there is react-native cli that will allow you to use and learn the basics of each platform for which you are developing, as gradle build system for Android and XCode for iOS. Even if you are using React Native, knowing the native side of each platform will take you further than Expo will allow you.
The final ideas on this topic are: avoid using Expo, maybe for a proof of concept it could work or an existing web application that you want to pass it to iOS and Android, but for a mobile application from scratch that involves a minimum viable product and from there go to grow the best is to go the way of react-natie cli.
After creating the project with react-native cli, it is convenient to create different folders, the first of them and that goes in the root of the project is the app folder.
Inside the app folder we will then create the following folders:
There are two types of navigation libraries, the JS navigator and the native navigator, except for a few occasions where performance is a primary factor, we will stay with the option of React Navigation, because it is the easiest to implement, it is easy to understand how to use it honestly the performance is not bad compared to the other.
Although the problem of screen sizes is not as big as when we develop for the web, it must be taken into account that our mobile app should be seen well from 3.5-inch to 7-inch smartphones through all kinds of resolutions.
To facilitate this work, the proposal is to use React Native Responsive Screen, this library allows us through the use of percentages to detect what screen size the app is in and adapt to it.
And for the cases in which with your React Native app you have to point towards tablets, web or desktop applications, the proposed library is Dripsy that when combined with the previous one you can easily define the size for each type of device.
Teaming up with other developers can be difficult if each of them has a particular way of writing code. There is an unwritten rule on this subject that says "Make it appear that the code was written by only one person even though there were several".
Code conventions can be as simple as always ending a statement with a semicolon. But to help us with the code convention we have at our disposal ESLint which will read the source code of our app and see if our preconfigured code conventions are followed by the developers, otherwise it will launch warnings and errors as the case may be.
Most of the IDEs and code editors have some plugin that supports ESLint, this allows that while you write code if something goes out of the convention the error is marked in the code and suggests corrections so that it can be fixed at the moment.
Choosing which rules our convention will have can be a demanding task, due to the large number there are and knowing the details of each one. The suggestion is to start with a pre-made convention such as the AirBnB code convention and from here see what works for them and what not for the development team. This code convention will be available to us by configuring it from eslint init once this library is installed and also has a convention for React projects.
It is useless to have a code convention if inconsistencies in the code still reach the code repository that most likely is on Github. For this we can rely on the Git Hooks, particularly two: pre-commit and pre-push, the Git Hooks are shell commands that you specify that would run after some git event, in this case we want that before being able to push to a git branch it is checked if our code is correctly linted, otherwise it does not allow push it, this can be used with other commands such as jest to run the unit tests and if any test fails does not allow pushing the code. To make sure everyone on the team has the shell commands for git hooks we can make use of the Husky library .
Developing mobile apps with React Native fits more into the category of frontend development than backend development, and traditionally in the frontend world the issue of unit testing is one that is neglected.
What is the use of testing UI code? Some of the reasons for promoting unit testing on the frontend is to catch bugs before the QA team does. With a code that has a good test coverage there is less chance of finding bugs. Doing unit testing it is common to describe what a method / function is supposed to do, what serves as documentation and that other current or future devs understand your code better and what you developed.
They serve as the basis to start refactoring code, why do they help you to ask yourself, how am I going to test this code? How do I make sure that every function I am going to write can be tested? And consequently that helps your code to become modular and in the future it will be easy to move parts or implement changes.
So contrary to what you might believe, writing unit tests does not increase development time, honestly the vast majority of time is spent debugging / fixing bugs, taking the time to do unit tests makes those actions less time consuming.
With all the previous points we should already have a good base on which to start working in a React Native app, it is true that some other points that were not touched have probably fallen by the wayside, such as good practices for Redux or what there is about Visual Unit Testing, among many other topics that even each of them, including those presented in this post, give for their own post in a more detailed way, however, with this basis, what is next?
On my part there is nothing left but to thank you for the time for reading this far, I hope that now or the future in some way what I read here can contribute something to you.
