Google OAuth 2.0
21st July 2021How Can PWA Benefit ECommerce Businesses in 2021?
22nd July 2021Don’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
- Writing
color = error ? ‘red’: ‘gray’
is short and sweet.
Writingcolor = 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.