Best practices for creating React Native apps — Part 1

If you are new to the React Native world, there are some pitfalls that you probably want to avoid while in some other cases you will have to make choices upfront maybe without knowing how important they are.

Below I have compiled a list of best practices from my personal experience, which I hope you will find useful 🙂

Use Expo-Kit only if you know exactly what you are doing

Expo is a free and open source tool-chain for React Native. It’s probably the best kit out there for React Native apps, but it comes with limitations.

Use Expo:

• If you want a quick playground and not to build your app’s repository. Just create a new app with the help create-react-native-app package.
• If you have done extended research of the app you are going to build and all its requirements can be covered from Expo’s offered solutions.
• If you don’t have a mac computer and you absolutely want to build your app for iPhone as well. It’s the only alternative on building executable IPAs.

Don’t use Expo:

• If you are new to React Native and you think this is the “must” way to go. Check if it meets your needs first.
• If you are planning to use third party RN packages that have custom native modules. Expo does not support this functionality and in that case, you will have to eject Expo-Kit. In my opinion, if you are going to eject any kit, don’t use it in the first place. It will probably make things harder than if you hadn’t used the kit at all.

Overall I think Expo is a great tool, and I use Expo Snack to share RN code snippets. But right now it can be of assistance only for building certain types of apps.

How to struct your application folders/files

Structuring you React Native app is no different from structuring your React app. So if you are familiar with that, you can stick with your existing logic. But if you are not, maybe you will find useful the logic proposed below:

• Add a folder in the root called “app”
• Create folders inside app:

assets — I use up to 3 folders in here: fonts, icons and images

components — This is where you’ll place all your shared React components. Usually these components are the ones that we call “dummy”, that have no state logic and can be easily reused across the app.

views — These are our application screens, the ones that we navigate from one to another. These are also React components, but they are the ones that we call containers, because they contain their own state.

modules — There are pieces that have no corresponding view part (JSX). Typical examples of that is the colors module (contains all the app colors) and the utils module (contains utility functions that are being reused).

services — These are the functions that wrap the API calls.

i18n — These are the translation strings for users of different language and locale

All apps require some type of configuration, so I usually create a file called config.js and put it in there. If the configuration file reaches a lot of lines, we can then create a config folder and separate the config in files.

If you have a state manager library, you will also need folders for its structs. In the case of Redux, 2 more folders are used, one for actions and another one for reducers. If you don’t use an external package and prefer to use React’s Context API, you will create your own providers, that can be placed either in modules folder or in a new folder called providers.

Choose a navigation library according to your needs from the very beginning

Unfortunately, RN has not provided a solid solution yet or even a replacement for old Navigator component, thus we are now focusing on community solutions. So if you are about to start a project, you want to know which navigation library to use and if it will be the right one for you.

Overall there are two types of navigation libraries. The JavaScript navigators and the Native navigators. The JavaScript ones are written in JavaScript while the Native ones are written as native modules of the respective platform (Android, iOS) and bridged to JavaScript modules in order to be invoked in the code. The former are much more easier to setup while the latter are much more performant. Spend the time to figure out which of them you need and then choose one from the many out there.

Spencer Carli has done a great job elaborating on the current Navigation choices in React Native world in this article which I suggest you to read. The dominant options though are React Navigation as a JavaScript solution and React Native Navigation as a Native solution.

Use a CSS-in-JS wrapper library for convenience

In React Native, CSS is written in JavaScript. It’s something that we have no choice about. Personally instead of using StyleSheet.create method and code CSS as pure JavaScript, I prefer using Styled Components library. Styled Components make writing CSS feel intuitive again and make the JSX look more semantic.

Recently, I wrote an article on why I prefer using Styled Components in React Native apps, so you can have a look there for more details.

Decide early how you want your app to “scale” across different devices and screen sizes

Chances are, you are developing an app for more that one device size and screen size. Now here there are two options on how to approach your design/development.

You can choose to have different UI/UX depending on the screen size. This is probably the best option for most types of applications but requires a lot of effort because there are multiple screens to be designed and implemented. Screens’ size can be identified through the Dimensions API. Alternatively, you can use a third party package that provides some utilities out of the box such as React Native Responsive UI.

Or you can choose to have the same UI/UX that will scale proportionally for all screen sizes. This is the best option when for example you are developing a game. Again, you can use a third party package to achieve that such as React Native Responsive Screen.

Disclaimer: I am the maker of React Native Responsive Screen package.

Approach animations with caution

Animations are very important for mobile apps but React Native’s performance is not at its finest yet.

In order to protect yourselves from delivering bad results you always need to test animations in device — emulator does not provide proper feedback. You also must make use of the prop useNativeDriver (with value set to true) wherever you can, because it will help you achieve better performance.

Keep also in mind…

1. React Native does not have DOM elements. Instead, we are dealing with native elements.
2. About CSS:

• Not all properties are supported; at least not yet. Check the documentation for more info: View Style Props, Image Style Props, Text Style Props
• Shorthand properties do not work well, so always prefer the specific ones (i.e. margin-bottom, margin-top, margin-left, margin-right instead of margin)
• Not all properties support percentage values. To mention a few: margin, border-width and border-radius. And if someone tries to set a percentage value, RN will either ignore it completely or the application will crash.
• RN provides flex support out of the box. Learn it and use whenever you can. It’s you best CSS ally!