Skip to main content

ADR-0021 — Reflexo em tela após ações do usuário

Status

Aprovado

Contexto

Telas com interação (formulários, diálogos, listas com ações) permitem que o usuário execute comandos que alteram dados no backend ou no estado da aplicação (ex.: troca de cargo, aprovar solicitação, salvar perfil, excluir item). Se a interface não for atualizada imediatamente após a ação bem-sucedida, o usuário fica em dúvida se a operação funcionou e pode repetir a ação ou fechar e reabrir a tela para “ver o resultado”.

É necessário um princípio único aplicável a todas as telas que possuem interação, para que o comportamento seja consistente em todo o app.


Decisão

Em qualquer tela que possua interação com o usuário (ações que alterem perfil, dados ou estado):

  • Após a execução bem-sucedida de um comando local (botão, confirmação, aprovação, exclusão, etc.) e das chamadas ou alterações decorrentes no backend ou no estado da aplicação, a tela deve refletir imediatamente as consequências dessa ação.
  • O usuário não deve precisar fechar e reabrir a tela, trocar de aba ou recarregar a página para ver o resultado.
  • Atualizações incluem, conforme o contexto da tela:
    • Dados exibidos (labels, listas, status)
    • Estado de seleção (chips, dropdowns, itens selecionados)
    • Conteúdo derivado do estado (ex.: combo “Cargo desejado” que depende do cargo atual)
    • Listas de itens (solicitações, pendências, etc.)

Regra de implementação: Após cada ação bem-sucedida, o estado local da tela (widget state, serviço em memória) deve ser atualizado a partir da fonte de verdade (backend ou serviço) e um novo build (setState ou equivalente) deve ser disparado para redesenhar a UI com os dados atualizados.


Escopo

  • Aplica-se a todas as telas e diálogos que oferecem ações que alteram dados ou estado (perfil, cargos, solicitações, preferências, listas crud, etc.).
  • TDDs e especificações de cada tela devem referenciar este ADR e descrever os reflexos esperados naquela tela (ex.: “Conforme ADR-0021: após confirmar troca de cargo, atualizar cargo atual, chips e combo Cargo desejado”).

Consequências

  • Desenvolvimento da camada de apresentação deve garantir atualização de estado e rebuild após ações que alterem dados.
  • Novas telas com interação devem ser implementadas e documentadas em conformidade com este princípio.
  • Alterações neste comportamento exigirão revisão deste ADR.

Referências

  • ADR-0009 — Princípios de Interface e Experiência do Usuário (feedback visual imediato, consistência)
  • TDD Tab Perfil na EBD — exemplo de aplicação: reflexos na aba “Perfil na EBD” após troca de cargo, solicitar, aprovar, rejeitar, excluir