Re-render é o mecanismo central do React. É o que mantém a interface sincronizada com o estado da aplicação. E ainda assim, é um dos pontos mais mal compreendidos por desenvolvedores React. Pergunte a um grupo de devs o que dispara um re-render e você vai ouvir respostas diferentes — a maioria incompletas, muitas incorretas.

O React re-renderiza componentes com frequência. E isso não é um problema — é o mecanismo que mantém a interface sincronizada com o estado da aplicação. O problema aparece quando re-renders acontecem sem necessidade: trabalho pesado sendo refeito desnecessariamente, componentes redesenhados sem que nada tenha mudado de verdade. É aí que `useMemo` e `useCallback` entram.

Eu nunca gostei muito de conteúdo sobre setup quando ele vira só uma lista de ferramenta. Sempre achei meio sem graça quando a pessoa fala o nome de tudo que usa, mas não mostra o que aquilo resolve na prática. Então a ideia aqui é mais simples: registrar o que eu uso hoje para trabalhar e por que esse fluxo faz sentido para mim.

Nos dois artigos anteriores, a base foi esta: primeiro, como o JavaScript executa código; depois, como o runtime organiza assincronismo com `Call Stack`, `Web APIs`, `Task Queue`, `Microtask Queue` e `Event Loop`. Agora o próximo passo é olhar para `Promise` e `async/await` sem tratar nada como mágica. A ideia aqui é entender onde essas abstrações entram naquele mesmo desenho que já começamos a montar antes.

JavaScript executa uma coisa por vez. Mesmo assim, `fetch`, `setTimeout`, eventos de clique e `async/await` continuam funcionando sem travar a aplicação. Para entender por quê, precisamos olhar para `Call Stack`, `Web APIs`, `Task Queue`, `Microtask Queue` e `Event Loop`.

Quando a gente começa a estudar JavaScript, é comum resumir a história assim: o código é executado linha por linha, e os valores necessários ficam guardados na memória. Esse modelo ajuda no começo, mas, para entender de verdade `Execution Context`, `Hoisting` e `Call Stack`, ele precisa ficar um pouco mais preciso.