Tips For React-Native Developers

Don’t bother with Expo

You should never use Expo on a serious project, for a number of reasons.
Firstly, the entire build process is not done locally, but in Expo cloud, which means little to no control and potential server issues while building. Secondly, you are adding another layer of complexity to your project, which slows it down and increases the app size.
Most importantly, native iOS/Android modules, which you are certain to need at one point, are not supported. The only native modules that are available to you are the ones provided by the Expo SDK.
Sooner or later, you will reach a point where you will have to eject the Expo app into a regular React Native app, so you might as well not waste your time and start the project right way anyway.

Use ESLint

Using a linter on any project is a must, especially for a wild language such as JavaScript. ESLint is a fantastic extension which is extremely easy to install, set up and use, so be sure to include it in your project from the very beginning. If you disagree with some of the rules, you can always disable them in the .eslintrc configuration file, but having some kind of code quality control is going to help you and your team immensely in the long run.

Remove all logs from your release builds

Having many console.log statements can slow your app down, especially if you are using logging libraries such as redux-logger. Be sure to disable all logs (manually or with a script) when making a release build.

Use Flexbox

This should really be a no-brainer, but sadly I’ve seen React Native code that uses absolute element positioning instead of flexbox, which breaks the layout and provides no reusability whatsoever. No matter what your design requirements are, using flexbox is almost always the correct answer. For those who come from web background: Flexbox in React Native works almost exactly the same as its CSS counterpart, the important difference being that flexDirection defaults to column instead of row in React Native.

Name your style objects consistently

If your root view has a style object named container, then use that name for every root view on the project. If your submit button has a style object named submitButton, then stick with it and don’t use saveButton, submitBtn or submit for other instances.

Think about smart and dumb components

This is extremely important for any React Native project because classifying your components as smart or dumb will help you organize your project logically and also reuse your components better.
Smart components, also called class-based or container components are concerned with how things work. This means they hold the state, fetch data from the API, do most of the computing, keep track of the lifecycle methods if needed, provide data to other components, and have no styling included. Dumb components, also called functional or presentational components are concerned with how things look. They simply receive data (props) through parent components and display it to the user. They usually have no state and minimal logic, and contain all the styling. They are highly reusable because they provide a simple functionality based on the input data.

Use ternary operators concisely

1. Writing color = error ? ‘red’: ‘gray’ is short and sweet.
   Writing color = error ? (id === myID) ? ‘red’ : ‘black’ : ‘gray’ is not. Ternary operators can help reduce the number of lines in your code but never nest them because the logic becomes difficult to read.

Don’t abuse zIndex

Use zIndex only when you have to. For example, if you want to overlay a <Text> over an <Image>, using zIndex is the wrong way to do it. You should use <ImageBackground> component instead. A good rule of thumb is that if you think you are over-complicating your code with a lot of zIndex properties, you are probably right. Go back to square one and rethink your layout.

Don’t leave sensitive data in your app

This includes API keys, API secrets, project IDs, client secrets, domains and any other data that is too sensitive to hold inside the app. Keep all of these on the server, not in your project.