React-Native Anti-Patterns

09 September 2020

While developing any application, there are some do’s and don’ts that we need to follow. Anti-patterns are the patterns which degrade the performance of the solution. It is possible that unknowingly we might implement the anti-patterns in our code. In React-native, there are few anti-patterns that are listed below.

Writing heavy computing logic in the render method

React native tries to maintain a display 60 frames per second to show the static image in the mobile application. React uses two threads for maintaining it namely Javascript Thread and Main thread. Javascript thread is responsible for maintaining the business logic, API calls and interactions of the application whereas the Main thread (also known as UI thread main) is responsible for the handling interface, animations and navigations between screens. Javascript thread communicates with native threads and provides the required data to the UI thread. Any lags to provide information to UI thread results into dropping the UI frames.

When one writes the computing logic (ex. performing the array prototype operations) in the render method, it is handled by the javascript thread. It is possible that the display frame rate dropped while performing the operation. Hence performing computing operations is one of the Anti-pattern.

Unconditionally copying props to the state

In the new update, the React has introduced us to the new lifecycle methods like getDerivedStateFromProps. Previously, react had only one method to update it’s prop called componentWillReceiveProps. These life cycles update the react component when there are any changes in the props or state. But there is also one case we often forget that is when the parent updates, the whole child component re-renders. This will lead to changing the state value to initially copied prop value. Also it will never allow us to update the child components state unless the props from the parent component changes. This is an anti-pattern.

Using index for the key prop

We all know that the React works on the virtual DOM concept where it compares the actual vs virtual DOM and updates the tree where it has changed. It is very important to know how react differs between the virtually updated tree and real DOM tree. For every different type of DOM element, react will generate new trees. So it is easy to differentiate and update the DOM when the component updates using a diffing algorithm.

When we need to render the same type of elements in react, react recommends us to use their key prop to differentiate between the similar components. Key should be unique.  When there is a need to render the same component using loop, we simply add index for the key prop. In the worst case, if the first children updates then the whole tree re-renders since the React is unable to find the similarity between virtual tree and real one. This causes performance loss of the application and it is an anti-pattern.

Using setState in componentDidUpdate lifecycle method unconditionally

ComponentDidUpdate lifecycle methods get triggered when there is any prop or state of the component will updated. When we call the setState method in this lifecycle, it will re-renders component and componentDidUpdate lifecycle will again be triggered. This will end up as an endless loop. Hence, it is recommended that they not perform any activity unconditionally that will update the component. Unless and until there is no other way to handle the situation, then only we should use the set state in the componentDidUpdate life cycle.