Web e frontend · Avançado

Gerenciamento de estado em um app web

Em uma linha: A maior parte do que se chama de estado são dados do servidor guardados no lugar errado — separe-os e metade da complexidade desaparece.

Quatro tipos de estado

Dados do servidor. Listas, itens, perfil. São cópias de uma fonte de verdade remota e precisam de tratamento de cache: carregamento, atualização, expiração.

Estado de interface. Um painel aberto, uma aba selecionada, texto digitado. Vive no componente, morre com ele.

Estado de endereço. Filtro, paginação, busca. Seu lugar é na URL — para poder compartilhar e navegar de volta.

Estado global de verdade. Usuário logado, tema, idioma. Pouquíssimas coisas.

O erro comum

Colocar tudo em um store global único. O resultado: cada tela depende de cada tela, dados ficam velhos sem que ninguém perceba, e bugs que aparecem só quando você chega em uma tela em determinada ordem.

Ao separar, a maior parte do código global evapora. O que fica é pequeno e fácil de entender.

O que precisa de tratamento explícito

Estados de carregamento e erro para cada busca, evitar requisições antigas que voltam depois de uma mais nova, e atualizações otimistas que saibam como reverter quando o servidor recusou.

Indo mais fundo

Defina uma política de frescor por tipo de dado — quanto tempo uma cópia é considerada válida e quando atualizar em segundo plano. Sem uma política explícita, cada tela inventa a sua, e aí 'por que isso não atualiza' vira um bug eterno.