UI = f(statesⁿ)

Artigo original ↗ Discussão no Hacker News ↗

O trabalho moderno de UI é enquadrado como “UI = f(state)”, mas desenvolvedores argumentam que aplicações reais — de frontends web a jogos — expõem muito mais estado entrelaçado e oculto do que a maioria dos modelos reconhece. Os comentaristas trocam experiências com máquinas de estados, fluxos de eventos e lógica determinística de jogos, debatem o quanto se deve “tornar estados ilegais não representáveis” e destacam como ferramentas como React, servidores no estilo LiveView ou XState ajudam a domar a complexidade, embora ainda deixem lacunas em sincronização, animação e comportamento multi-cliente. Muitos veem o desenvolvimento de jogos e a modelagem formal de estados como prática valiosa para entender esses problemas mais profundamente.

Desenvolvimento de jogos e modelagem de estado

  • Vários comentaristas defendem construir jogos simples (por exemplo, paciência, jogos de ação básicos) para internalizar que toda possibilidade visual deve existir em algum estado em algum lugar.
  • Mesmo jogos “simples” rapidamente revelam muito mais estado do que os diagramas iniciais sugerem, especialmente com rede, prevenção de trapaças e replay/determinismo.
  • Jogos de tabuleiro/cartas complexos (por exemplo, Wingspan, Magic: The Gathering) são vistos como intimidadores; as pessoas citam máquinas de estados, programação orientada a eventos, pilhas e documentos de regras como ferramentas para entender e modelar tais sistemas.
  • Há debate sobre quão alcançável é o networking determinístico, dado o comportamento de ponto flutuante, divergência do tipo caos e diferenças entre plataformas; abordagens lockstep são vistas como difíceis, mas possíveis.

UI = f(state): benefícios e limites

  • Muitos concordam que, em princípio, a view é uma função pura do estado; jogos, sistemas de replay e views de dev/debug são citados como fortes evidências.
  • Outros enfatizam que “estado” deve incluir estado intermediário/apenas da UI: entrada parcial de formulário, erros de validação, flags de carregamento, progresso de animação etc.
  • O exagero de “estados ilegais são não representáveis” pode prejudicar a UX (por exemplo, reclamar de e-mail inválido enquanto o usuário digita); alguns argumentam que estados úteis não devem ser modelados como ilegais.
  • É sugerida uma separação mais clara entre:
    • estado do domínio (dados validados),
    • estado do widget de UI (o que o usuário está fazendo agora),
    • e o mapeamento entre eles.

Eventos, ações e máquinas de estados

  • Alguns propõem pensar em termos de fluxos de eventos: state = reduce(state, event) e view = fn(state), com handlers despachando eventos em vez de mutar diretamente.
  • Outros formulam como view, effects = fn(state, events) ou modelos centrados em ações; críticos observam que isso normalmente volta a uma formulação de máquina de estados.
  • Máquinas de estados e ferramentas/bibliotecas para elas são repetidamente recomendadas como uma forma de domar a complexidade.

Complexidade e arquitetura de frontend

  • Aplicações de navegador são descritas como múltiplos loops de eventos locais mais sistemas remotos/distribuídos, com ferramentas fracas e muito acopladas por cola em comparação com ecossistemas de backend.
  • Frameworks como React são vistos como bons em “state → DOM”, mas não responsáveis pelos problemas completos de sincronização de dados (tempo real, offline, colaboração); outras ferramentas (queries, camadas de sync) preenchem lacunas, muitas vezes de forma incoerente.
  • Alguns defendem abordagens centradas no servidor/estilo LiveView, mantendo a maior parte do estado e da renderização no servidor para simplificar o raciocínio.
  • Carregamento/fetching é destacado como multieestado (carregamento inicial vs atualização vs append), e bibliotecas que distinguem “loading” de “fetching” são elogiadas.

Animações, transições e estado implícito

  • Transições/animações desafiam a visão ingênua de “UI = f(state” quando os dados mudam antes de as animações terminarem.
  • Correções sugeridas: tratar o status/progresso da animação como estado explícito, ou confiar em animação declarativa no nível da plataforma enquanto se mantêm os estados inicial/final no estado da aplicação.
  • No geral, o consenso tende para: “é tudo estado”, mas parte dele é implícita ou tratada pela plataforma.