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
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.