Blog

Grande parte da qualidade de uma base React não vem de hook avançado, otimização exótica ou biblioteca nova. Vem da API dos componentes.

Quando um Server Component renderiza no servidor, a saída principal não é HTML. Também não é um JSON qualquer saindo de um endpoint. O que o React produz ali é um payload próprio, feito para transportar árvore de componentes, referências de módulos, valores especiais de JavaScript e unidades de trabalho que podem chegar progressivamente pela rede. Esse payload é o **React Flight**.

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.