O problema com o useEffect: por que seu efeito dispara mais do que deveria

O useEffect é um dos hooks mais mal compreendidos do React, não por ser complexo, mas porque sua semântica de sincronização com o mundo externo colide com a mentalidade declarativa do framework. A raiz técnica dos bugs não está no hook em si, mas na forma como o React valida dependências: comparação estrita por referência, não por valor. Isso significa que qualquer função definida inline, objeto ou array criado dentro do componente gera uma nova referência a cada render, mesmo que seu conteúdo seja idêntico. O ESLint com react-hooks/exhaustive-deps flagra isso, mas muitos desenvolvedores desabilitam a regra para 'resolver' loops, ignorando que isso cria closures obsoletas, um erro silencioso que só aparece em produção, com dados desatualizados ou requisições duplicadas.

O problema se agrava em aplicações com Server Components e Next.js, onde o ciclo de vida do efeito pode divergir entre servidor e cliente. Isso já foi exposto na cobertura anterior sobre a falha React2Shell: protocolos como Flight dependem de sincronização precisa entre camadas, e efeitos instáveis comprometem essa garantia. Além disso, o Strict Mode do React 18, que executa efeitos duas vezes em desenvolvimento, não é apenas uma curiosidade: é um detector de efeitos não idempotentes. Se seu useEffect não lida bem com múltiplas execuções (ex.: inicia dois timers sem limpeza), ele já está quebrado, e o React 19 vai tornar esse comportamento ainda mais crítico com novas primitivas como use() e useActionState, que reduzem drasticamente a necessidade de useEffect para busca de dados e submissão de formulários.

Na cobertura anterior de 2026-05-21 sobre a falha React2Shell, destacamos que o protocolo Flight exige consistência rígida entre cliente e servidor, e efeitos instáveis são vetores de inconsistência. Agora, com a notícia atual, vemos a confirmação prática: o mau uso do useEffect não é só um problema de performance ou UX, mas de segurança arquitetural. Enquanto antes alertávamos sobre riscos teóricos no protocolo, agora há evidência concreta de como dependências mal gerenciadas propagam erros em toda a pilha, desde vazamentos de memória até condições de corrida em requisições assíncronas. Também evoluiu o entendimento sobre mitigação: não basta usar useCallback; é preciso questionar *se* o efeito é necessário, o React 19 está empurrando os devs para substituir useEffect por APIs mais especializadas, como use() para dados e useActionState para formulários.

Um useEffect que dispara demais não é só um 'bug chato': ele consome CPU desnecessariamente, impede a virtualização eficiente de listas (como no componente CodeView descrito em 2026-06-01), atrapalha o controle nativo de rolagem (citado em 2026-05-25) e pode até expor vulnerabilidades em Service Workers, como o bug do Chromium reportado em 2026-05-25, que depende de ciclos de execução contínuos para manter bots ativos. Em termos de DX, o efeito instável força devs a depender de ferramentas externas (TanStack Query, SWR) para corrigir o que deveria ser resolvido na camada de abstração do React. Isso fragmenta a stack e aumenta a curva de aprendizado. A correção começa com disciplina: estabilizar referências, nunca omitir dependências e encarar o useEffect como um escape hatch, não como o cérebro do componente.