# State and data flow > CrossFly's state philosophy — no reactive binding, no DI, imperative + explicit invalidation. Source: https://crossfly.dev/docs/concepts/state-and-data-flow — CrossFly documentation. Full docs as one file: https://crossfly.dev/llms-full.txt # State and data flow This is where CrossFly most surprises those coming from Flutter, Compose, SwiftUI, or React. Two deliberate absences: - **There is no automatic reactive binding.** No `setState`, observables, `@State`, or recomposition. Changing the model does **not** update the UI on its own. - **There is no dependency injection container.** No Dagger/Guice/Spring. You build and pass your dependencies by hand (typically through the screen's constructor). ## The model: imperative + explicit invalidation You **read/write the model**, **update the component directly**, and the framework **repaints**: ```java model.nome = "Ana"; label.setText(model.nome); // most setters already invalidate the layout and call repaint() ``` Most component setters already fire `repaint()`/invalidate the layout for you. The single rule to remember: > **Changed state the framework doesn't know about** (a counter of yours, a computation, a field drawn in > `onPaint`)? **You** call `repaint()`. (See [The paint thread](/docs/concepts/the-paint-thread).) ### The classic counterexample ```java this.progresso = 0.7f; // I changed a field that only my onPaint reads… // …and the screen doesn't change. Missing: Component.repaint(); // ✔ now the next frame reflects the new value ``` "I changed the state and the screen didn't update" is, almost always, a missing `repaint()`. ## Why this choice - **Predictability:** the flow is linear and visible — data → setter → repaint → frame. There is no magic recomposition nor hidden reactive cycle to debug. - **Zero magic, low cost:** no reactive dependency graph, no DI framework to configure. - The price is explicitness: **managing state is the application's responsibility**, not the framework's. ## The communication mechanisms the framework offers - **Callbacks / actions** — `onAction(...)`, callbacks passed through the constructor (see [Returning results](/docs/ui/navigation/returning-results)). - **Parent/child hierarchy** — navigate the component tree. - **`property(k, v)`** — the per-component "data bag" (see [Everything is a Component](/docs/concepts/everything-is-a-component)). - **Global state** — static fields/shared services when it makes sense. ## The recommended pattern Since the framework only provides the building blocks, the organization pattern (a **ViewModel/controller** per screen + **repository** for data) is an application convention — documented in [best-practices](/docs/best-practices). The framework does not impose an architecture; it offers components and the setter→`repaint()` pair.

## See also - Related: [The paint thread](/docs/concepts/the-paint-thread) · [App architecture (best-practices)](/docs/best-practices)