In my previous article (React Native Tips and Tricks, part 1), I described 10 things to consider when doing react native development/ mobile development. Let's delve into the 2nd part of the article that elaborates further on the topic.

11. Mind the iOS Safe Area.

When developing an app, it can be challenging to ensure that it looks great on all iOS devices, especially regarding view blockage. One common issue is when the content on a screen gets cut off or obscured by the device's bezels or notch.

Using a <SafeAreaView> component in React Native ensures that the app looks great on all iOS devices, regardless of size or shape. You can even create a wrapper component with additional features, such as an indication for offline notice. This approach not only enhances the app's visual appeal but also ensures that all content is easily accessible and not hidden by the device's hardware.

12. Implement empty placeholders when there is no data.

Maintaining a professional look for your app is essential, even when missing data. To do this, consider using vacant placeholders, such as images or simple labels informing users that no content is available. This can prevent users from being met with an empty screen, negatively impacting their first impressions. By enhancing the user experience in this way, you can ensure that new users receive your app well.

13. Clean up parameters that aren't used in components anymore.

It's possible that some of the props a component receives may not be needed anymore if it has been extensively reworked. Regular cleanup will result in cleaner code and a clearer understanding of how data flows through your application.

14. Organize your constant.

It's crucial to maintain a separate file for all your configuration variables, such as navigation bar height, side menu width, and page size for API requests, enums, and other variables, making it easier to modify whenever needed.

Similarly, keeping all your colors in one file instead of hardcoding HEX values all over the project will aid you in tracking every value. Even for colors like black and white, since design requirements can change due to different factors such as rebranding or altering the product owner. It is essential to name the colors carefully - use a generic name like COLOR_BASE instead of a specific color name.

Finally, keeping all your message strings in one localization file makes them easy to translate if necessary and is a good practice even if you don't plan to translate your app anytime soon.

Keep all of your configuration variables as named constants in a separate file so you can always discover and modify them. Examples include navigation bar height, side menu width, page size for API requests, enums, and so on.

The same goes for colors. Instead of hardcoding HEX values all over the project, keep all your colors in one file so you can always keep track of every value. And yes, you should make constants even for black and white colors, because design requirements can be changed later (due to rebranding, the project owner has been changed etc.), and you might need to change all black colors in your project to a different shade of black, or a different color altogether. Be sure to revise and clean this file up regularly so it doesn’t get cluttered with old, unused values. Naming your colors properly is also important. If your main app color is blue, don’t name the constant because if it gets changed to red later, you will have to rename every single instance to COLOR_RED. Use COLOR_BASE instead.

15. Constantly check how the app looks on different platforms and devices

You will ultimately save a ton of time and work if you are continuously aware of how your app appears on different screen sizes (larger phones, smaller phones, and tablets). Additionally, consider the other platform even if you are just creating for one. For instance, using ActionSheetIOS on Android won’t work, so you’ll either need to redo that code or come up with a different solution afterwards.

16. Choose a variable naming style and stick with it

You like camelCase? Great. Or are you more of an snake_case person? That’s also great. We will not go into which approach is better, because both have pros and cons. The important thing is to pick one and stick to it, and not mix them together. Be consistent.

17. Increase touchable area with hitSlop

If you have a small button that is hard to press, you could increase padding values to increase touchable area, but you can also use a property hitSlop to achieve the same purpose.

18. Handle keyboard issues

A keyboard is every mobile developer’s nemesis. Have you ever encountered an issue where you are presented with a list of clickable rows, but because your keyboard is open, you have to tap twice: the first time to close the keyboard and the second time for the row to react and open a screen? React Native’s <ScrollView> and<FlatList> , both have a useful property called keyboardShouldPersistTaps. Setting its value to “always” will prevent this nasty behaviour from happening. Another issue that often happens is the keyboard overlapping the text input fields you’re supposed to type in. Luckily, there are libraries out there such as react-native-keyboard-avoiding-scrollview, which prevent this inconvenience from happening.

19. Avoid setting the width and height of container components

If your component’s child components already have set dimensions, double-check if it’s really necessary to set dimensions for the container component as well. Sometimes it can be useful, but more often than not it’s better to let the container components resize themselves based on the dimensions of their children.

20. Be aware of your code complexity

It's essential to be mindful of the computational complexity of your code. Sometimes, a component might spend more time processing the received data than waiting for a server response. You can use tools like Visual Studio extensions that provide code metrics to keep track of your code complexity in each method. This allows you to optimize your entire codebase. However, it's important to remember that the performance of a released app on an actual device can differ significantly from the debug version on your simulator or emulator. So, avoid the pitfall of premature optimization, as it can lead to unwanted consequences. As Donald Knuth once said, "Premature optimization is the root of all evil."

Thank you for reading!