Increase React render performance by avoiding unnecessary useEffects

Increase React render performance by avoiding unnecessary useEffects

A common mistake I see people making while creating their React component is creating extra states and effects. That may cause unexpected bugs and extra renders.

Let's say that we have a simple app that generates a full name based on the value of two given inputs (first and last names) as shown below.

Application exemple with two fields and a title

The approach that I mostly see developers using is creating an extra state for the full name, and in an useEffect set this state according to the new values in the inputs:

const [firstName, setFirstName] = useState<string>("");
const [lastName, setLastName] = useState<string>("");
const [fullName, setFullName] = useState<string>("");
 
useEffect(() => {
  setFullName(`${firstName} ${lastName}`);
}, [firstName, lastName]);

That's not the right approach… But, why?

Basically what happens is:

React lifecycle flow with an extra state and effect

The right approach

When something derives from an existing prop or state we should always calculate it during render time. That avoids bugs that could be generated because of the extra states and increases performance because of the fewer renders.

const [firstName, setFirstName] = useState<string>("");
const [lastName, setLastName] = useState<string>("");
 
const fullName = `${firstName} ${lastName}`.trim();

With this new approach, our component lifecycle gets reduced to:

React lifecycle flow with a derived state

Comparing the two approaches

When comparing the two approaches with the name "James Robert" we see that the first approach does twice as much renders and has substantially more code than the second one.

First approach total renders: first render + 2 x number of letters in the name.

Print screen with the amount of re-renders in the first approach

Second approach total renders: first render + number of letters in the name.

Print screen with the amount of re-renders in the second approach

In this test case, since it is just a proof of concept, we will not see a big difference performance-wise, but in real-life features, we should always care about this kind of issue.

Code

If you want, you can take a look at the code used in the article:

References

Other Blog Posts

How to create a new GitHub Release through Azure Pipelines
How to create a new GitHub Release through Azure Pipelines

Creating a new GitHub release is a common task that a lot of developers are supposed to do during their careers. But on the other hand, it is not as well documented as it could. There are a lot of little tricky things that you will discover only during the process.

Pare de escrever seus componentes React dessa forma
Pare de escrever seus componentes React dessa forma

Após algum tempo trabalhando como desenvolvedor React Native, percebi a tendência das pessoas em estruturarem as sua árvore de componentes com renders condicionais baseados em ifs ternários

ESLint + Prettier, a dupla perfeita para produtividade e padronização de código.
ESLint + Prettier, a dupla perfeita para produtividade e padronização de código.

Padrões de código estão se tornando cada vez mais importantes por conta do crescimento dos times de desenvolvimento e a alta rotatividade do mercado de desenvolvedores.