# Estado y flujo de datos > La filosofía de estado de CrossFly — sin binding reactivo, sin DI, imperativo + invalidación explícita. Source: https://crossfly.dev/es/docs/concepts/state-and-data-flow — CrossFly documentation. Full docs as one file: https://crossfly.dev/llms-full.txt # Estado y flujo de datos Es aquí donde CrossFly más sorprende a quien viene de Flutter, Compose, SwiftUI o React. Dos ausencias deliberadas: - **No hay binding reactivo automático.** Nada de `setState`, observables, `@State` ni recomposición. Cambiar el modelo **no** actualiza la UI por sí solo. - **No hay contenedor de inyección de dependencias.** Nada de Dagger/Guice/Spring. Tú construyes y pasas tus dependencias a mano (típicamente por el constructor de la pantalla). ## El modelo: imperativo + invalidación explícita Tú **lees/escribes el modelo**, **actualizas el componente directamente** y el framework **repinta**: ```java model.nome = "Ana"; label.setText(model.nome); // la mayoría de los setters ya invalida el layout y llama a repaint() ``` La mayor parte de los setters de componente ya dispara `repaint()`/invalida el layout por ti. La regla única a recordar: > **¿Cambiaste estado que el framework no conoce** (un contador tuyo, un cálculo, un campo dibujado en el > `onPaint`)? **Tú** llamas a `repaint()`. (Ver [La paint thread](/docs/concepts/the-paint-thread).) ### El contraejemplo clásico ```java this.progresso = 0.7f; // cambié un campo que solo mi onPaint lee… // …y la pantalla no cambia. Falta: Component.repaint(); // ✔ ahora el próximo frame refleja el nuevo valor ``` "Cambié el estado y la pantalla no se actualizó" es, casi siempre, un `repaint()` faltante. ## Por qué esta elección - **Previsibilidad:** el flujo es lineal y visible — dato → setter → repaint → frame. No hay recomposición mágica ni ciclo reactivo escondido que depurar. - **Cero magia, bajo costo:** sin grafo de dependencias reactivo, sin framework de DI que configurar. - El precio es la explicitud: **gestionar el estado es responsabilidad de la aplicación**, no del framework. ## Los mecanismos de comunicación que ofrece el framework - **Callbacks / actions** — `onAction(...)`, callbacks pasados por constructor (ver [Devolver valores](/docs/ui/navigation/returning-results)). - **Jerarquía padre/hijo** — navegar el árbol de componentes. - **`property(k, v)`** — el "saco de datos" por componente (ver [Todo es un Component](/docs/concepts/everything-is-a-component)). - **Estado global** — campos estáticos/servicios compartidos cuando tenga sentido. ## El patrón recomendado Como el framework solo da los bloques, el patrón de organización (un **ViewModel/controller** por pantalla + **repositorio** para los datos) es convención de la aplicación — documentado en [best-practices](/docs/best-practices). El framework no impone arquitectura; ofrece componentes y el par setter→`repaint()`.

## Ver también - Relacionado: [La paint thread](/docs/concepts/the-paint-thread) · [Arquitectura de app (best-practices)](/docs/best-practices)