Cheat Sheet

Some common references and special components supported by React Native, Android back handler, and a bit of know-how!

Cheat sheet#

Over the journey of the course, we have seen quite a few best practices relating to different segments of the React Native ecosystem. This page is an attempt at a quick reference guide for these along with ideas and solutions for something we may be looking to build or solve.

General pointers#

Build yourself rather than using external libraries where possible. Do not rely too much on them unless trying to do heavy lifting.

  • Scrollview is good for screens and modals but should be avoided for long lists.

  • SectionList is a wrapper over VirtualizedList (the same as Flatlist). These are better if we need to render multiple sections with header and/or footer support. Find more details below.

  • A flatlist inside a flatlist is a bad idea. If somehow you still need to do this, I would recommend going back to the drawing board. You may have a very valid use case, but this is where the platform may start hitting its limitations.

  • ErrorBoundary - have an error boundary component, at least at root level. And always log and monitor production errors in error boundary components.

  • Shadows are memory-intensive. Use them sparingly.

  • Compress the images used in-app, especially the ones that go in the React Native bundle. These are sent with every codepush, and can cost a lot of bandwidth for the users.

Components#

SectionList#

Common user experiences like sticky headers for sections, section footers, and headers, can be built using SectionList. Apart from renderItem, SectionList also requires sections: an array of objects that will be rendered in each section.

For the complete API for SectionList, refer to the official docs.

ActivityIndicator#

This is used to customize the loading indicator of the app and provide that additional brand experience to the users.

For the complete ActivityIndicator API, refer to the official docs.

BackHandler - Android#

Androids have a hardware back button, unlike iOS. While this has been mostly replaced with an on-screen back button, it is still provided by the OS and is not something we build in-app.

We may need to handle the back button in some cases, like when closing a modal, or when alerting a user that they may be about to exit the app accidentally.

For the complete API for BackHandler, refer to the official docs.

ActionSheetIOS#

Start a new discussion. All notification go to the author.