React Myths And Legends

Rate this content
Bookmark

The talks explore various misleading patterns and concepts in React, that seem to be “common knowledge”, but which a lot (if not most) developers either get wrong or are just not aware of those. Some examples, covered in the talk (and more):
* that “react component re-renders when its props change” (this is not true)
* that wrapping a component in React.memo will prevent its re-render (not always true)
* that use of Context causes re-renders and is bad for performance (not always true, sometimes Context can actually reduce the number of re-renders in the app)
* that creating an element like this `const A = <Child />` is when the Child's render lifecycle is triggered (not true)

Nadia Makarevich
Nadia Makarevich
22 min
06 Jun, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

This talk discusses myths and misconceptions in React that can impact re-renders. It covers unnecessary re-renders and the misconception that props trigger re-renders. The talk also explores the role of memoization and context in reducing re-renders. Additionally, it highlights the importance of using the key attribute correctly to optimize rendering. The talk concludes by discussing the separation of state and API in context and the use of state management tools like Redux.

Available in Español

1. Introduction to Myths and Legends in React

Short description:

Welcome to the talk about myths and legends in React. My name is Nadia, and I've been a developer for a very long time. Today, I want to share a few myths and misconceptions that can negatively impact re-renders in all apps. But before that, let's quickly remember what is mounting, re-renders, and unnecessary re-renders in React.

Hi, everyone. Welcome to the talk about myths and legends in React. Let me start with a little bit of an introduction. My name is Nadia. I've been a developer for a very long time. I worked for Atlassian for about five years on a product that some of you might know and love called Jira. Until very recently, I lived in Australia just surrounded by parrots and kangaroos. But a few months ago, I got tired from all this nice weather and perfect beaches and I moved to Austria for the only reason that I am lazy and Austria is easier to spell.

Also, I am a bit of a nerd. One of my nerd hobbies is to investigate how things work in detail and then write deep dive articles on those topics. I usually write for front-end developers, more specifically React developers. One of the main focus for those investigations, the thing that interests me the most recently is React Performance. And the topic of performance in React is crazy interesting. React is a fantastic tool that allows us to write complicated applications really easily and quickly. But as a result, it's also very easy to write code that will result in our applications being very slow and lagging. And most of the time, it's because of re-renders. We either re-render too fast or too many or too heavy components. So the key to good performance in React is knowing and being able to control when components are mounting and re-render. And then prevent those that are unnecessary.

So today, I want to share a few myths and misconceptions that are quite common among developers and that can negatively impact re-renders situation in all apps. But before doing that, let's quickly remember what is mounting, re-renders and what are unnecessary re-renders. It all starts with mounting. This is the first time the component appears on the screen. This is when React initializes and wires everything together, thus initial render fires all the callbacks and use effects for the first time. After that, if your app is interactive, it will be time for re-renders. Re-render is when React updates an already existing component with some new data. Those are usually happen as a result of user interacting with your interface or some external data coming through. Re-renders are a crucial part of React lifecycle. Without those, there will be no updates to the interface, and as a result, no interactivity. So it's not something that we would want to get rid of.

2. Unnecessary Re-renders and the Big Re-renders Myth

Short description:

Unnecessary re-renders occur when the entire app re-renders on every keystroke, negatively impacting performance. The Big Re-renders Myth states that a component re-renders when its props change, but this is not true. Re-renders are triggered by state changes, which propagate updates to other components recursively.

Unnecessary re-renders, however, is a completely different story. Imagine a React app, just a tree of components like any other app, and somewhere at the bottom of this tree, we have an input-filled component where a user can type something. When this happens, I want to update the state of this input and everything related to the user data, like showing some helpful hints while the user is typing. This is re-render. The last thing that I want, though, is for the entire app to re-render itself on every keystroke. Imagine how slow the typing in this field will be if something like this happens. This is definitely not something anyone would call a performance app. This is an example of unnecessary re-renders, and those are exactly the type of re-renders we would want to get rid of.

And when it comes to preventing re-renders, there is this big myth that somehow everyone believes. I call it the Big Re-renders Myth. It goes like this. A component re-renders when its props change. It's amazing, really. Everyone believes it. No one doubts it. And it's just completely not true. To understand that, let's dig a little bit deeper into why re-renders happen in the first place. It all starts with state change. Any React developer will probably recognize the code. We have a parent component. It renders a child component and it has a useState hook. When setState is triggered, the entire parent component will re-render itself. State change is the initial source of all re-renders. It's the king of re-renders so to speak. That's why it's in the crown. After the state change, it's time for React to propagate this update to other components. React does this recursively. It grabs direct children of a component with state, re-renders those, then re-renders children, and so on until it reaches the end of component's tree or is stopped explicitly. This is the next reason for a component to be re-rendered when its parent component re-renders. If we look at the code, once the state change in parent component happens, all children that this component has will re-render as a result.