DEV Community: César O. Araújo

A árdua batalha da Memoização no React

César O. Araújo — Wed, 30 Jul 2025 16:45:24 +0000

This is a translation of the original post The Uphill Battle of Memoization by TkDodo

Já existem muitos conteúdos excelentes por aí sobre o que você poderia fazer antes de usar React.memo. O post do Dan Abramov chamado "before you memo" ("Antes de você memoizar" em tradução livre) e o "Simples truque para otimizar re-renderizações no React" do Kent C. Dodds são dois ótimos exemplos de leitura sobre o tema.

A ideia é deixar a composição do componente resolver o problema para você, seja ao mover o state (Estado da Aplicação) para baixo ou movendo o conteúdo para cima. Isso é brilhante porque a composição de componentes é o modelo mental natural do React. Como o Dan mostrou, isso também vai funcionar bem com Server Components, que agora já são realidade.

O que está faltando na a maior parte dos artigos que eu li é o porquê. Sim, a composição é ótima, mas qual o problema ao usar React.memo? Por que não é tão bom quanto a primeira opção?

Então aqui vai a minha opinião sobre isso:

"Memoização" é muito fácil de quebrar

Para recapitular: Quando o React renderiza uma árvore de componentes, vai fazê-lo de cima para baixo (top-down), para todos os componentes "filhos". Uma vez que uma renderização começa, não existe maneira de fazermos ela parar. No geral, isso é uma coisa boa, por que renderizações nos fazem ter certeza de que nós estamos vendo a versão correta e mais atual do nosso estado na tela. Além disso renderizações em geral são rápidas.

E aí existem aqueles edge cases (casos de rara ocorrência) onde elas não são. Todos nós temos aqueles componentes que não renderizam tão rápido quanto gostaríamos e que por alguma razão nós não podemos mudar. Para nossa sorte, o React ainda pode "abortar" renderizações e vai fazê-lo se enxergar "a mesma coisa", isto é, se nada mudou (props ou estado). Isso é o que faz técnicas como mover o conteúdo para componentes acima funcionarem:

function App() {
  return (
    <ColorPicker>
      <p>Hello, world!</p> {/* Conteúdo movido */}
      <ExpensiveTree /> {/* Conteúdo movido */}
    </ColorPicker>
  )
}

function ColorPicker({ children }) {
  const [color, setColor] = React.useState('red')
  return (
    <div style={{ color }}>
      <input
        value={color}
        onChange={(event) => setColor(event.target.value)}
      />
      {children} {/* Estava aqui anteriormente */}
    </div>
  )
}

Se os "filhos" (children) possuem exatamente a mesma referência, o React pode fazer um curto-circuito na renderização. Mesmo que Color mude, o componente ExpensiveTree não vai re-renderizar por isso.

A solução alternativa seria continuar renderizando tudo dentro do mesmo componente, mas adicionar o React.memo ao redor do componente ExpensiveTree.

function App() {
  const [color, setColor] = useState('red')
  return (
    <div style={{ color }}>
      <input
        value={color}
        onChange={(event) => setColor(event.target.value)}
      />
      <p>Hello, world!</p>
      <ExpensiveTree /> {/* Chamar o componente normalmente */}
    </div>
  )
}

function ExpensiveComponent() {
  return <div>I'm expensive!</div>
}

const ExpensiveTree = React.memo(ExpensiveComponent) // Uso do React.memo

Se adicionarmos um React.memo ao redor do componente, o React vai pular a renderização deste componente (e todos os seus componentes-filho) se as suas props não mudaram. Isso certamente vai alcançar o mesmo resultado de quando mudarmos a composição do componente, mas será bem mais fácil de quebrar no futuro.

Quando um componente é "memoizado", o React vai comparar cada prop com Object.is. Se as props não mudaram, a re-renderização será abortada/pulada. Isso funciona perfeitamente no nosso exemplo atual, por que nosso componente atualmente não recebe nenhuma prop. Também vai funcionar com valores primitivos como props, mas não tão bem com funções, objetos e arrays.

Vamos fazer uma alteração aparentemente inofenciva no nosso ExpensiveComponent - adicionando estilos com a prop style.

function ExpensiveComponent({ style }) {
  return <div style={style}>I'm expensive!</div>
}

const ExpensiveTree = React.memo(ExpensiveComponent)

Isso é como os componentes evoluem geralmente ao longo do tempo - props são adicionadas. O ponto é: os componentes que invocam o componente ExpensiveTree não necessariamente sabem que ele está "memoizado". Afinal, isso é apenas uma otimização de performance e um detalhe de implementação.

Se nós adicionarmos uma prop style inline ao renderizar nosso componente ExpensiveTree:

<ExpensiveTree style={{ backgroundColor: 'blue' }} />

Nós, inadvertidamente, arruinamos nossa "memoização". porque a prop style será um novo objeto a cada nova renderização. Para o React, parece que as props mudaram, então não é possível pular a renderização.

Ok, certo, nós podemos consertar isso ao usar React.useMemo no objeto de estilo:

function App() {
  // "memoizando" o objeto de estilo
  const memoizedStyle = React.useMemo(
    () => ({ backgroundColor: 'blue' }),
    []
  )

  return <ExpensiveTree style={memoizedStyle} />
}

Isso é possível no nosso exemplo simplificado, mas imagine como nosso código iria parecer se nós tivéssemos mais props que precisam ser "memoizadas". Isso faria nosso código parecer mais difícil de analisar, e não existem garantias de que os componentes que usam este componente iriam realmente fazer essa "memoização".

Fica ainda mais difícil quando o estilo em si é passado como uma prop para o componente que renderiza o ExpensiveTree:

function App({ style }) {
  const memoizedStyle = React.useMemo(() => style, [style])

  return <ExpensiveTree style={memoizedStyle} />
}

Essa "memoização" não traz benefício algum. Não sabemos se o estilo será passado como um objeto inline para o App, então memoizá-lo aqui não faz sentido. Seria necessário criar uma referência estável no ponto onde o App é chamado.

{children}

O que é pior - Esta não é a única forma de como nossa melhora de performacne pode quebrar. Outro "A-há!" é que componentes "memoizados" não vão funcionar como se espera se eles aceitam a prop children.

function App() {
  return (
    <ExpensiveTree>
      <p>Hello, world!</p> {/* Parágrafo passado como children */}
    </ExpensiveTree>
  )
}

function ExpensiveComponent({ children }) {
  return (
    <div>
      I'm expensive!
      {children} {/* children */}
    </div>
  )
}

const ExpensiveTree = React.memo(ExpensiveComponent)

Ufa! Preciso admitir - Por muito tempo eu não sabia que isso quebraria a memoização. Afinal, por que quebraria? Eu estou sempre passando a mesma e estável tag <p> como children, certo? bom... não na verdade. O JSX é apenas uma sintaxe simplificada para a função React.createElement, que vai criar um novo objeto a cada nova renderização. Então, mesmo que a tag <p> pareça a mesma para nós, ela não terá a mesma referência na memória.

A gente até pode envolver os componentes filhos que estamos passando para o componente "memoizado" com useMemo também, mas espero que você já esteja notando que estamos travando uma batalha quase impossível de vencer. O próximo programador pode simplesmente vir e passar um objeto ou array vazio como valor de fallback para uma prop do nosso componente memoizado — e aí voltamos à estaca zero.

A Alternativa

Usar o React.memo pode ser como andar em um campo minado, e escolher uma das alternativas propostas me parece uma escolha melhor para mim. Mas às vezes, aparentemente não podemos evitar memoizar um componente. Vamos dar uma olhada em um exemplo que vi no X (ex twitter) que me deu a ideia para criar este blog post:

Eu raramente preciso adicionar otimizações de performance no React.

Mas nós temos uma página com 5 tabelas grandes e uma barra de resumo. Quando uma tabela muda, tudo renderiza novamente. É lento.

Solução:
1. Envolvi cada tabela em um memo.
2. Envolvi as funções que passei para baixo em um useCallback.

MUITO mais rápido.
— Cory House (@housecor) September 28, 2023

Eu esperaria que a árvore de componentes parecesse algo como isto (Estou usando duas tabelas ao invés de cinco por brevidade):

function App() {
  const [state, setState] = React.useState({
    table1Data: [],
    table2Data: [],
  })

  return (
    <div>
      <Table1 data={state.table1Data} />
      <Table2 data={state.table2Data} />
      <SummaryBar
        data={calculateSummary(state.table1Data, state.table2Data)}
      />
    </div>
  )
}

state possui os dados de ambas as tabelas, e o SummaryBar precisa de acess a todos esses dados. Nós não podemos mover o estado para baixo (para dentro das tabelas), e nós também não podemos compor os componentes de uma forma diferente. Parece que a memoização é a nossa única opção.

Não comece renderizando

Lembra de quando eu disse que uma vez uma renderização começa nós não temos nenhuma forma de pará-la? Isso ainda é verdade, mas e se nós parássemos a renderização no começo...? 🤔

Se o estado da aplicação (state) não estivesse no topo do componente App, nós não precisaríamos re-renderizar toda a arvore quando o estado mudasse. Mas onde nós o colocaríamos então? Nós já estabelecemos que nós não podemos movê-lo para baixo (para o componente filho) - Então vamos colocar o estado ao lado: fora do React.

Isso é precisamente o que a maioria das soluções de gerenciamento de estado fazem. Elas guardam o estado da aplicação fora do React e cirurgicamente disparam re-renderizações de partes da árvore de componentes que precisam saber das mudanças no estado. Se você já utilizou o React Query antes, isso é exatamente o que está acontecendo lá também. Sem essa técnica, você veria muito mais re-renderizações do que gostaria.

Então sim, minha solução alternativa proposta é trazer um gerenciamento de estado efetivo. Eu vou usar Zustand porque é o que mais estou familiarizado a utilizar.

const useTableStore = create((set) => ({
  table1Data: [],
  table2Data: [],
  actions: {...}
}))

export const useTable1Data = () =>
  useTableStore((state) => state.table1Data)
export const useTable2Data = () =>
  useTableStore((state) => state.table2Data)
export const useSummaryData = () =>
  useTableStore((state) =>
    calculateSummary(state.table1Data, state.table2Data)
  )

Agora todo componente pode se inscrever internamente para o estado que mais lhe interessa, evitando qualquer renderização de cima para baixo (top-down). Se table2Data atualizar, Table1 não vai ser renderizado novamente. Esta é tão efetivo quanto memoizar as tabelas, mas não vai sofrer com pegadinhas geradas ao adicionar novas props que podem impactar negativamente a performance.

Uma saída

Garantido, todas as soluções presentes aqui não são perfeitas. Memoização em geral faz o nosso código ser mais difícil de ler, e mais fácil de implementar errado (o que torna a pior opção para mim). Usar gerenciadores de estados externos é um pouco melhor - você pode ter essa dependencia na sua aplicação de qualquer forma. Adaptando a forma que você compõe componentes ainda é a melhor opção, mas nem sempre é possível.

O que realmente poderia ser uma saída seria se nós mudássemos as regras do jogo. Records e Tuples são propostas ECMAScript que estão em estágio 2 há algum tempo, nos ajudaria com Arrays e objetos, mas não com funções. Sebastien Lorber tem um ótimo artigo sobre isso.

O time do React também tem dado dicas de que eles estão trabalhando em um compilador chamado "React Forget", que supostamente vai memoizar tudo para nós automaticamente. Dito isto, nós poderíamos ter otimizações de performance do React.memo sem margem para erro.

Striping down the Prototype Chain

César O. Araújo — Sat, 04 Dec 2021 15:18:03 +0000

Sometimes I feel that a bunch of developers try to learn JavaScript but they only focus on top-level abstractions and they choose the path of learning the what it does, and not how it is done.

With that being said, let me ask you something: Do you know how something is evaluated as undefined under the hood?

If you don't know how it works, this article is for you, little Padawan.

It's all about prototypes

Whenever you see a class in JavaScript you're being lied about it. There's no such thing in JS. It is all about prototypes.

The ES2015 release brought the concept of "classes" into the world and the people use it a lot. Some of them don't know that classes are just a syntactical sugar. In the end, JS is a prototype-based language.

🔑 Prototype access on objects and functions

In order to add properties to objects you can use __proto__:

 const myObject = { x: 1 }

 myObject.__proto__.y = 2

However if you intend to add properties to functions, you need to use the prototype access:

 const myFunction = function() { this.a = 1 }

 myFunction.prototype.b = 2

The Prototype Chain

JavaScript has only one construct: Objects.

Each one of these objects has a private property called prototype. Prototype is also an object therefore it contains the prototype property on its own. This chain continues until the last prototype has the value of null.

Okay, but let me show you a practical example before you fall asleep:

// Create a real simple object
const myCustomObject = {
  x: 1,
  y: 2
}

If you put this on your browser's console and console log it you'll see something like this:

As you can see, there's the expected properties from the object x and y plus the [[prototype]] object.

Try to expand this last one:

There's a lot of things inside of it: a constructor, and some functions which can be used by this object. Each one of these have a prototype on its own. Expand them and check it out.

But again: the prototype itself has a __proto__ (same as [[prototype]]). Ok, let's expand it until the very end of the chain.

[...] and that's the end of the prototype chain. That's all, folks...

Just kidding, haha

Inheritance

Before we enter on the last topic of this article I would like to show you a little bit about how the inheritance happens with this prototype-based thing.

let myCustomFunction = function () {
   this.x = 1;
   this.y = 2;
}

// create a new object from myCustomFuncion()
// with its own properties
let instanceOfMyCustomFunction = new myCustomFunction(); 

// add two new properties to myCustomFunction's prototype
myCustomFunction.prototype.y = 3;
myCustomFunction.prototype.z = 4;

Hm, right... Let's see how interesting all of this is.

  console.log(myCustomFunction.x); // 1
  console.log(myCustomFunction.y); // 2
  console.log(myCustomFunction.z); // 4
  console.log(myCustomFunction.t); // undefined

Wait, wait, wait... y is not 3? how's that?! 👀

JS will look for a given property by checking the object properties first, then it will check the first prototype and so on until it finds the __proto__: null.

Check this out:

// JS finds the `x` property on myCustomFunction object
console.log(myCustomFunction.x); // 1

// JS finds the `y` property on myCustomFunction object
console.log(myCustomFunction.y); // 2

Ok, but why the heck this is 2 and not 3? That's simple:

JS will return the first result found. In this case, 2 is the first value found.

If there was no y property on the base of the object, JS would search for it on object's prototype.

This is exactly what is happening with the z property:

// JS doesn't find the `z` property on myCustomFunction object
// so it searches on its prototype, where it's available
console.log(myCustomFunction.z); // 4

Finally, when no value is found, JS assume that the property is not defined therefore the undefined value shows up:

// there's no `t` property whatsoever on the prototype chain.
console.log(myCustomFunction.t); // 4

One last example

let myCustomFunction = function () {
   this.x = 1;
   this.y = 2;
}

myCustomFunction.prototype.foo = "bar"

let instanceOfMyCustomFunction = new myCustomFunction(); 

instanceOfMyCustomFunction.prop = "some value"


console.log(instanceOfMyCustomFunction.prop); // some value
console.log(instanceOfMyCustomFunction.foo); // bar
console.log(myCustomFunction.prop); // undefined
console.log(myCustomFunction.foo); // undefined
console.log(myCustomFunction.prototype.prop); // undefined
console.log(myCustomFunction.prototype.foo); // bar

I hope this helps you to understand better what's going on under the JS' hood and if I missed something, let me know by commenting on this article!

Thanks for reading! See ya!

[Clean Code][PT-BR] Guards: You shall not pass!

César O. Araújo — Mon, 19 Jul 2021 13:35:40 +0000

Oi, gente!!!
deixa eu te perguntar uma coisa: você já sentiu a dor de ver um código como esse abaixo?

 if (email && email.includes('@')) {
   if(password && password.trim() !== '') {
     // DO SOMETHING
   }
 }

É só um exemplo, mas imagine 4 a 7 ifs aninhados.

Criar pedaços de código assim é uma prática realmente comum pra quem tá iniciando como dev e é até saudável que façam isso porque, na minha opinião, um programador precisa sentir a dor de escrever um código sujo pra entender o valor do Clean Code.

Ifs aninhados podem realmente ser uma dor de cabeça se crescerem muito mas a gente consegue limpar usando algo chamado Guards (Guardas).

Guards?

Esse é um conceito bem simples de entender: eles basicamente verificam se existe algo errado, exemplo: validações, e então param a execução da sua função.

function usandoGuards(email, password) {
 if(!email || !email.includes('@')) {
   console.log('Email não é válido');

   return; // Aqui é onde a mágica acontece
 }

 if(password && password.trim() !== '') {
   // Faz alguma coisa
 }

}

Como você pode ver no código acima, o primeiro if é o nosso Guard. Ele vai parar a execução se um email inválido for passado. Simples, né?!

O código ainda está sujo por causa dos níveis de abstração mas eu não vou abordar esse assunto nesse artigo. Fica pra um próximo hehehe. Vamos focar nos Guards por ora.

O conceito de Guards é uma forma simples de evitar criar ifs aninhados. Ah, você também pode ter vários Guards:

function usandoGuards(email, password) {
 if(!email || !email.includes('@')) {
   console.log('Email inválido');

   return; // that's where the magic happens
 }

 if(!password && !password.trim() === '') {
   console.log('Password inválido');

   return;
 }

 // Faz alguma coisa
}

Agora que estamos usando nossos Guards do jeito certo, estamos livres pra escrever qualquer lógica de negócio abaixo porque, no fim, já estamos fazendo a validação com os Guards.

Uma última dica: a necessidade de usar Guards pode ser identificada de forma fácil se você tiver um if-else onde no else, você tem a saída negativa:

 if (user) {
   // Faz alguma coisa
 } else {
  console.log('esse é um erro!');
 }

Tente fazer isso sozinho e vai ver a legibilidade do seu código aumentar!

NOTA: Todos os exemplos foram feitos com JavaScript mas você pode usar a linguagem da sua preferência pois os princípios são os mesmos.

Alguma opinião ou algo a acrescentar? esqueci de algo? não tenha medo e deixe seu comentário!

Obrigado por ler! =)

[Clean Code] Guards: You shall not pass!

César O. Araújo — Mon, 19 Jul 2021 13:11:47 +0000

Hi everyone!! let me ask you something: have you ever felt the pain when looking at a code like this one below?

 if (email && email.includes('@')) {
   if(password && password.trim() !== '') {
     // DO SOMETHING
   }
 }

This is just an example, but imagine a 4-7 nested if statements.

It is indeed common to beginners create pieces of code like that and even healthy because, in my opinion, a programmer must feel the pain of writing a dirty code to catch the value of Clean Code.

Nested if statements can really be a pain in the ass if they get too big but we can clean this up using something called Guards

Guards?

This is a really simple concept to understand: They basically verify if there is something wrong, i.e validations, and then you stop the execution of your function.

function usingGuards(email, password) {
 if(!email || !email.includes('@')) {
   console.log('Email is not valid');

   return; // that's where the magic happens
 }

 if(password && password.trim() !== '') {
   // DO SOMETHING
 }

}

As you can see on the code above, the first if condition is now our Guard. It will stop the execution if an invalid email is passed. Really simply, right?

The code is still dirty because of its abstraction levels but I'm not going to talk about it on this article. Just focus on the Guards for now.

It's a simple way of avoiding really nested if statements. You also can have more than one Guard, check this out:

function usingGuards(email, password) {
 if(!email || !email.includes('@')) {
   console.log('Email is not valid');

   return; // that's where the magic happens
 }

 if(!password && !password.trim() === '') {
   console.log('Password is not valid');

   return;
 }

 // DO SOMETHING
}

Now that we are using our Guards in the right way, we are free to write any code related to the business logic because in the end, we're doing the validation with our Guards.

One last quick tip: The need of usage of Guards can be easily identified if you have a if-else statement where the else is the negative output:

 if (user) {
   // DO SOMETHING
 } else {
  console.log('that's an error!');
 }

Try to do this on your own and see your code readability increase!

NOTE: I'm doing this with JavaScript but you can do it with any other language, the principles are the same.

Do you have opinions or something to add? don't be afraid, leave a comment!

Thanks for reading! =)

How to get the difference between two arrays

César O. Araújo — Mon, 19 Oct 2020 00:40:03 +0000

Hey, everyone! how are you guys doing? :)

I recently passed through a situation where I needed to get the difference between two arrays.

Messing around with arrays is a kind of tricky sometimes so I decided to share a simple solution for this specific case.

Let's declare two simple arrays:

 const initialNumbers = [1, 2, 5, 7, 3]

and

 const initialWithMoreNumbers = [1, 2, 4, 7, 9, 5, 3]

Alright, now we must find the intersection between them.

Arrays have some great methods provided by ES6+ features like filter.

With Array.filter() we can loop through an array and make some logic for every item in the array.

let result = initialWithMoreNumbers.filter(number => number)

the code above will return every item in a new array, but we can do more than this, right?

we can verify if an item of the first array is NOT included in the second one like this:

let result = initialWithMoreNumbers.filter(number => !initialNumbers.includes(number))

after return, our result will be:

console.log(result) //[4, 9]

And how about array of objects?

If you need to compare keys in objects inside arrays, you just need to add a new method called array.every() to loop again and search what you need:

const people = [{name: 'cesar', age: 23}]
const morePeople = [{name: 'cesar', age: 23}, {name: 'kevin', age: 26}, {name: 'pedro', age: 25}]

let result2 = morePeople.filter(person => people.every(person2 => !person2.name.includes(person.name)))

array.every() will loop through an array and return each element that passed on the test provided. In this case, if the name of the person in the second array does not contains the name of the person in the first one.

You can try this out by yourself with the age field!

Hope it helps! see ya!

Multi params requests using Axios

César O. Araújo — Sat, 29 Aug 2020 14:17:36 +0000

Axios is an easy and widely used when we talk about fetching data. But have you ever had problems with multi query params?
Let's check how to do it properly then! :)

QueryStrings

Working with QueryStrings, in general, can be an easy task, but sometimes we can face more specific situations that make the game a little bit more tricky.

Okay, but what the heck is a QueryString??
You may have seen some URLs that have the following format:

https://www.yourdomain.com/user?id=3

QueryStrings are part of the URL that contain an information that helps the backend to choose what it will be searching for in the database.

The example above shows a GET method searching for user with id equals to 3.

More than one param

Now let's think about lists!
Lists are great, right?! so we gonna imagine a scenario where we need to access a list of users that live in a given city and has a given age.

We can pass more than one param to the URL separating them with an "&" sign like this:

https://www.yourdomain.com/users?city=chicago&age=22

easy, right?!

The problem

What if we need to tell the backend to send users from two different cities and different ages?

Well, when working with checkbox type filters we have a problem.

So let's check this case out:

We have these filters in a Vue.js with Vuex application and everytime we click in an option an action is dispatched sending these params in an Object structure to a "filters" array in our state:

filters: [
 {"key" = "city", "value"="chicago"},  
 {"key" = "city", "value"="ohio"},
]

Now that we have the needed information in the state, we can make our request with Axios after setting up the base url:


// Action
async GET_USERS() {

// Since we have mixed filters as objects in an array
// we must map them creating a new array with their values
  const cityParams = state.filters.map((filter) =>
      filter.key === 'city' ? filter.value : undefined
    )

  const ageParams = state.filters.map((filter) =>
      filter.key === 'age' ? filter.value : undefined
    )

  const data = await this.$axios.get('/users', {
    params: {
      city: cityParams,
      age: ageParams
    },
  })
}

It looks simple, but we still have a problem. If we click in a "22 age" checkbox, we will get the following url:

https://yourdomain.com/users?city[]=&age[]=22

If we click again in another age, for exemple 18:

https://yourdomain.com/users?city[]=&city[]=&age[]=22&age[]=18

Maybe the first one will work, if the backend is correctly identifying the keys ending with []. However the second one will break your request returning a 400 status code (bad request).

Solving it

This can be solved by using QS package.

Basically it will allow us to stringify the array of params (cityParams and ageParams).

After download the package using npm or yarn and import it, we can pass it as a third argument in the axios request as it follows:

import qs from 'qs';

// Action
async GET_USERS() {

// Since we have mixed filters as objects in an array
// we must map them creating a new array with their values
 const cityParams = state.filters.map((filter) =>
      filter.key === 'city' ? filter.value : undefined
    )

const ageParams = state.filters.map((filter) =>
      filter.key === 'age' ? filter.value : undefined
    )

  const data = await this.$axios.get('/users', {
    params: {
      city: cityParams,
      age: ageParams
    },
    paramsSerializer: (params) => {
      return qs.stringify(params, { arrayFormat: 'repeat' })
    },
  })
}

Note that when we map the params, we must return undefined if there is no value.

The values null and '' (empty string) return the key with empty value by default. Otherwise, undefined omit the whole param.

the following argument will repeat key=value for every value we have in the array.

{ arrayFormat: 'repeat' }

As result, we have a clean and readable URL (again clicking twice in checkboxes from age filter):

https://yourdomain.com/users?age=22&age=18

That was a little bit tricky but incredibly useful, right?!

Hope it helps! :)

DEV Community: César O. Araújo

A árdua batalha da Memoização no React

"Memoização" é muito fácil de quebrar

{children}

A Alternativa

Não comece renderizando

Uma saída

Striping down the Prototype Chain

It's all about prototypes

🔑 Prototype access on objects and functions

The Prototype Chain

Inheritance

One last example

[Clean Code][PT-BR] Guards: You shall not pass!

Guards?

[Clean Code] Guards: You shall not pass!

Guards?

How to get the difference between two arrays

And how about array of objects?

Multi params requests using Axios

QueryStrings

More than one param

The problem

Solving it

**"Memoização" é muito fácil de quebrar**