De Quem e Esse Estado?

O problema

Muitas interfaces ficam confusas porque o time começa a criar estado para tudo antes de checar se aquele valor realmente precisa existir.

Em pouco tempo, o mesmo dado aparece em vários lugares, uma parte da tela depende da outra para continuar coerente e os usuários começam a reportar bugs “aleatorios”.

Na maior parte das vezes, o problema não e React nem Vue. O problema e não existir um dono claro para cada informação.

Modelo mental

Bom estado e estado com dono claro.

Se um valor pode ser calculado a partir de props ou de outro estado, normalmente ele não deveria ser salvo de novo.

Se duas partes da interface dependem do mesmo dado, alguém precisa ser declarado a fonte unica de verdade.

Uma forma útil de pensar e esta:

• estado e o que precisa ser lembrado
• derivado e o que pode ser recalculado
• bug costuma aparecer quando os dois ficam misturados

Quebrando o problema

Quando olhar para um valor na UI, faca estas perguntas:

1. Esse valor realmente muda com interação do usuário ou resposta de rede?
2. Eu consigo calcular isso durante a renderização a partir do que já tenho?
3. Quem e a fonte de verdade desse valor?
4. Isso precisa ser compartilhado globalmente ou pode ficar local?

Essas perguntas evitam estado inventado e desnecessario.

Também ajudam a evitar outro erro bem comum: subir estado cedo demais. Nem tudo que e usado em mais de um lugar precisa virar store global. As vezes só precisa subir um nivel. As vezes nem isso.

Exemplo simples

Imagine uma pagina com lista de usuários e um campo de busca.

Uma abordagem confusa salva tres coisas:

• users
• searchQuery
• filteredUsers

O problema e que filteredUsers não e uma verdade nova. Ele e só o resultado de aplicar searchQuery em users.

Uma modelagem melhor salva só:

• users
• searchQuery

E calcula a lista filtrada durante a renderização.

Isso elimina sincronização manual e reduz muito a chance de mostrar dado desatualizado.

Outro exemplo comum e modal aberta com isOpen e selectedUser.

Se a interface só abre modal quando existe selectedUser, guardar os dois pode criar incoerencia:

• isOpen = true
• selectedUser = null

Em bastante caso, basta guardar selectedUser e derivar a abertura da modal a partir disso.

Erros comuns

• Guardar estado que poderia ser derivado no render.
• Criar duas fontes de verdade para o mesmo valor.
• Subir estado para store global ou componente pai cedo demais.
• Compartilhar estado pela aplicação sem definir um dono claro.

Tem um erro mais sutil também: guardar copia local de prop só para “facilitar”. Quase sempre isso só cria mais um lugar para o valor ficar atrasado.

Como um senior pensa

Quem tem mais experiência não começa perguntando “onde eu coloco esse useState?”.

Começa perguntando:

“Esse valor realmente precisa existir como estado ou eu posso derivar isso da verdade que já tenho?”

Responder isso direito costuma simplificar bastante o componente antes mesmo da primeira linha de código.

Senioridade aqui aparece em resistir ao impulso de modelar tudo como memória mutavel. Interface clara normalmente nasce quando menos coisa precisa ser sincronizada.

O que o entrevistador quer ver

Em entrevista de frontend, esse raciocínio mostra maturidade.

• Você separar verdade principal de valor derivado.
• Você respeitar a ideia de fonte unica de verdade.
• Você justificar quando um estado precisa ser local e quando precisa ser global.

Uma resposta forte costuma soar assim:

“Antes de criar estado, eu tento descobrir se esse valor realmente muda por evento externo ou se eu consigo derivar ele do que já tenho. Se consigo derivar, prefiro não armazenar porque isso reduz sincronização e chance de incoerencia.”

Guardar estado demais parece flexivel no primeiro dia e vira um pesadelo de sincronização pouco depois.