React. What is a “rerender” (I)
In this article you will be able to learn everything behind a “rerender” in React: what causes them, how to avoid them, and patterns and anti-patterns to take into account to optimize our applications.
--
In my opinion, understanding the key concepts of a library is essential if we want to feel comfortable working with it. That is why I wanted to write an article focused on the cornerstone on which React was created: the “renders”. Despite the evolution that it is undergoing in the last months, React has not separated from that initial idea by which we create interfaces through components that return JSX.
Understanding this process that we know as “rendering” and the events that trigger it is key if we want to design optimized applications while laying the foundation for further improvement. One way or another, when we work with React we end up talking about “renders”, so why not learn how they work?
I have decided to divide the content of this article about React and “rerenders” into two parts so that it does not end up too long and you have time to process the information.
What is a “render” in React?
Let’s start at the beginning and see what the concept of “render” means. For me, a “render” is the process by which React sends the JSX returned by a component to the DOM. The component calculates this JSX from 3 elements:
- Received properties.
- Its state.
- The value of the contexts it consumes from the Context API.
A component is rendered as long as it appears somewhere in the component tree that we have generated.
