# Estado e fluxo de dados > A filosofia de estado do CrossFly — sem binding reativo, sem DI, imperativo + invalidação explícita. Source: https://crossfly.dev/pt/docs/concepts/state-and-data-flow — CrossFly documentation. Full docs as one file: https://crossfly.dev/llms-full.txt # Estado e fluxo de dados É aqui que o CrossFly mais surpreende quem vem de Flutter, Compose, SwiftUI ou React. Duas ausências deliberadas: - **Não há binding reativo automático.** Nada de `setState`, observáveis, `@State` ou recomposição. Mudar o modelo **não** atualiza a UI sozinho. - **Não há contêiner de injeção de dependência.** Nada de Dagger/Guice/Spring. Você constrói e passa suas dependências à mão (tipicamente pelo construtor da tela). ## O modelo: imperativo + invalidação explícita Você **lê/escreve o modelo**, **atualiza o componente diretamente** e o framework **repinta**: ```java model.nome = "Ana"; label.setText(model.nome); // a maioria dos setters já invalida o layout e chama repaint() ``` A maior parte dos setters de componente já dispara `repaint()`/invalida o layout por você. A regra única a lembrar: > **Mudou estado que o framework não conhece** (um contador seu, um cálculo, um campo desenhado no > `onPaint`)? **Você** chama `repaint()`. (Ver [A paint thread](/docs/concepts/the-paint-thread).) ### O contraexemplo clássico ```java this.progresso = 0.7f; // mudei um campo que só o meu onPaint lê… // …e a tela não muda. Falta: Component.repaint(); // ✔ agora o próximo frame reflete o novo valor ``` "Mudei o estado e a tela não atualizou" é, quase sempre, um `repaint()` faltando. ## Por que essa escolha - **Previsibilidade:** o fluxo é linear e visível — dado → setter → repaint → frame. Não há recomposição mágica nem ciclo reativo escondido para depurar. - **Zero mágica, custo baixo:** sem grafo de dependências reativo, sem framework de DI para configurar. - O preço é explicitude: **gerenciar estado é responsabilidade da aplicação**, não do framework. ## Os mecanismos de comunicação que o framework oferece - **Callbacks / actions** — `onAction(...)`, callbacks passados por construtor (ver [Retornar valores](/docs/ui/navigation/returning-results)). - **Hierarquia pai/filho** — navegar a árvore de componentes. - **`property(k, v)`** — o "saco de dados" por componente (ver [Tudo é um Component](/docs/concepts/everything-is-a-component)). - **Estado global** — campos estáticos/serviços compartilhados quando fizer sentido. ## O padrão recomendado Como o framework só dá os blocos, o padrão de organização (um **ViewModel/controller** por tela + **repositório** para dados) é convenção da aplicação — documentado em [best-practices](/docs/best-practices). O framework não impõe arquitetura; ele oferece componentes e o par setter→`repaint()`.

## Veja também - Relacionado: [A paint thread](/docs/concepts/the-paint-thread) · [Arquitetura de app (best-practices)](/docs/best-practices)