Server State vs UI State vs URL State sem Misturar Tudo

O problema

Uma das formas mais comuns de complicar frontend é tratar qualquer valor mutável como se fosse o mesmo tipo de estado.

Daí aparecem coisas como:

• resultado de API copiado para useState
• filtro importante guardado só em memória
• estado visual indo parar em store global
• query string ignorada em tela que claramente precisa ser compartilhável

O efeito não vem na primeira tela.

Vem depois:

• refresh perde contexto
• sincronização fica frágil
• debug fica chato
• o time discute ferramenta quando o problema era modelagem

Modelo mental

Nem todo estado é igual.

Uma separação simples já melhora bastante:

1. server state
2. UI state
3. URL state

Em frase curta:

arquitetura frontend melhora quando você para de perguntar só “onde guardo isso?” e começa a perguntar “que tipo de estado é esse?”.

Quebrando o problema

Server state

Server state é o que vem de fora e cuja verdade principal não está no browser.

Exemplos:

• lista de pedidos
• perfil de usuário
• saldo atual
• resultado de busca no backend

Esse estado tem características próprias:

• pode ficar stale
• precisa de refetch ou invalidação
• pode depender de cache
• não pertence de verdade ao componente

O erro comum é puxar dado remoto e imediatamente duplicar tudo em estado local sem necessidade.

UI state

UI state existe para controlar a experiência visual e interativa.

Exemplos:

• modal aberta
• item selecionado
• aba ativa
• valor temporário de input
• expansão de accordion

Esse estado normalmente:

• nasce e morre com a interação
• é local por padrão
• não precisa sobreviver a refresh

Quando ele vai parar em store global sem motivo, a aplicação fica mais pesada de entender.

URL state

URL state é o que precisa ser compartilhável, navegável ou restaurável.

Exemplos:

• busca
• filtro
• ordenação
• paginação
• aba importante da tela

Se o usuário aperta refresh ou copia a URL, faz sentido que esse contexto continue?

Se sim, vale considerar a URL como dona.

O erro clássico

Muita tela mistura tudo assim:

• usa query para buscar dados
• copia resultado remoto para estado local
• guarda filtro só no componente
• usa efeito para sincronizar tudo de volta

Isso cria uma mini máquina de sincronização sem necessidade.

Quase sempre existe um desenho mais limpo.

Exemplo simples

Imagine uma tela de usuários com:

• busca
• filtro por status
• ordenação
• lista remota
• modal de detalhes

Uma divisão melhor seria:

• server state: lista de usuários vinda da API
• URL state: busca, filtro, ordenação e página
• UI state: modal aberta e usuário selecionado

Isso deixa claro:

• o que precisa sobreviver ao refresh
• o que precisa ser reconsultado
• o que é só comportamento visual

Agora compare com a versão bagunçada:

• tudo no componente
• vários useEffect sincronizando query string
• cópia local da resposta da API
• modal dependendo de dados duplicados

É a mesma feature.

Mas uma versão é legível. A outra vira areia movediça.

Erros comuns

• Guardar server state como se fosse UI state.
• Ignorar URL em telas que o usuário precisa compartilhar ou revisitar.
• Subir UI state para escopo global sem necessidade.
• Resolver modelagem ruim com mais efeitos de sincronização.

Como um senior pensa

Quem tem mais repertório costuma perguntar:

• a verdade desse dado mora onde?
• isso precisa sobreviver a refresh?
• isso precisa ser compartilhável por link?
• isso é dado remoto, dado visual ou contexto de navegação?

Essas perguntas cortam muito ruído antes mesmo da escolha de biblioteca.

O que isso muda no time

Quando a separação fica clara:

• menos sincronização manual aparece
• refresh para de parecer bug aleatório
• o fluxo de dados fica mais previsível
• o time consegue discutir arquitetura com menos confusão semântica

No fim, bastante “complexidade de estado” é só estado mal classificado.

Nem todo valor mutável é do mesmo tipo.

Quando você mistura donos diferentes, o frontend cobra essa dívida rápido.