Effects Sem Bagunca

O problema

useEffect vira bagunca rápido quando passa a ser usado como fita adesiva para qualquer coisa estranha na tela.

De repente, tem effect derivando estado, tentando sincronizar variaveis que nem deveriam existir e remendando ordem de renderização no susto.

O código pode até funcionar hoje, mas logo fica difícil prever quando algo roda e por que rodou.

Modelo mental

Effect não existe para controlar o ciclo de renderização do React.

Effect existe para sair do React e sincronizar o componente com o mundo externo:

• fazer um fetch
• iniciar um setInterval
• assinar um listener global
• integrar uma biblioteca externa que mexe no DOM de forma imperativa

Se a lógica pode ser calculada no render ou resolvida dentro de um handler de clique, ela provavelmente não pertence a um effect.

Uma heuristica simples ajuda bastante:

• se não existe sistema externo envolvido, desconfie do effect

Quebrando o problema

Antes de escrever useEffect, faca estas perguntas:

1. Com qual sistema externo eu estou tentando sincronizar este componente?
2. Eu consigo calcular esse valor normalmente durante o render?
3. Essa ação deveria acontecer apenas porque o usuário clicou em alguma coisa?
4. O cleanup esta obvio para quando o componente desmontar?

Responder isso com honestidade elimina boa parte dos effects desnecessarios.

Também evita um erro comum: usar effect para “forcar ordem” quando o problema real era estado mal modelado ou responsabilidade mal separada.

Exemplo simples

Olhe esta armadilha comum:

const [filteredUsers, setFilteredUsers] = useState<User[]>([])

useEffect(() => {
  setFilteredUsers(users.filter((user) => user.name.includes(search)))
}, [users, search])

Parece inocente, mas filteredUsers e totalmente derivado de users e search.

Aqui você esta forçando um segundo passo de renderização só para manter sincronizado um estado que nem precisava existir.

A versão mais previsivel e esta:

const filteredUsers = users.filter((user) => user.name.includes(search))

O código fica mais fácil de ler e você remove um re-render desnecessario.

Outro caso comum e submit de formulario:

• ruim: guardar um shouldSubmit no estado e usar effect para disparar a chamada
• melhor: fazer a chamada direto no handler de submit

Quando o gatilho e uma ação explicita do usuário, o handler normalmente e mais claro do que um effect esperando um estado mudar.

Erros comuns

• Usar effect para derivar ou espelhar estado.
• Colocar lógica de clique ou envio de formulario dentro de effect em vez de usar handlers.
• Confiar no array de dependências para “consertar” uma modelagem ruim.
• Esquecer cleanup em timer, subscription ou listener.

Tem outro erro frequente: usar effect para copiar prop em estado local sem motivo forte. Isso costuma criar mais um ponto de sincronização para dar errado.

Como um senior pensa

Quem tem mais experiência não olha para um effect perguntando “qual dependência esta faltando?”.

Pergunta isto:

“Eu estou mesmo sincronizando com um sistema externo ou só usando effect para compensar uma modelagem ruim de estado?”

Essa pergunta mata metade dos effects de uma base antes mesmo do commit.

Senioridade aparece aqui em preferir menos magia e mais fluxo previsivel. Effect bom costuma ser pequeno, explicavel e claramente conectado a algo fora do React.

O que o entrevistador quer ver

Em entrevista de React, como você lida com side effects mostra bem seu nivel.

• Você entender para que um effect realmente existe.
• Você separar sincronização externa de derivacao interna.
• Você priorizar previsibilidade, cleanup e evitar render em cadeia.

Uma resposta forte costuma soar assim:

“Eu uso effect quando preciso sincronizar o componente com algo externo, como fetch, timer, listener ou biblioteca imperativa. Se eu consigo resolver no render ou no handler, prefiro isso porque deixa o fluxo mais previsivel.”

Effect bom conecta o componente ao mundo externo. Effect ruim só tapa buraco de modelagem.