# Todo es un Component

> La idea unificadora de CrossFly — solo existe Component, y container = Component + Layout.

Source: https://crossfly.dev/es/docs/concepts/everything-is-a-component — CrossFly documentation. Full docs as one file: https://crossfly.dev/llms-full.txt

# Todo es un Component

Esta es la idea que hace que el resto del framework "encaje". En CrossFly **no hay una jerarquía de "widgets"
frente a "containers"**. Existe **un** tipo base — `Component` — y cualquier `Component` se convierte en un
container en el momento en que recibe un `Layout`.

## `container = Component + Layout`
```java
Component painel = new Component();       // un Component "vacío"
painel.setLayout(new VerticalLayout());   // ahora organiza los hijos → es un container
painel.add(LAY_AUTO, new Label("Título"));
painel.add(LAY_FILL, new ListView<>(...));
```
Un `Button` es un `Component`. Un `Label` es un `Component`. Una `Window` (pantalla) es un `Component` de
pantalla completa. **No existe una clase `Container` especial** — la "capacidad de contener" es solo tener un
`Layout`. Esto significa que compones pantallas de la misma manera, siempre, desde el botón hasta la app entera.

## Por qué la clase base está diseñada así
`Component` necesita escalar a **miles de instancias** sin explotar la memoria. Dos decisiones clave:

- **Bitfield (`cbits`) en vez de decenas de `boolean`.** Estados como *enabled*, *visible*, *focused*,
  *pressed*, *tiene layout*, *tiene estilo enfocado*… son bits de un único entero long, no campos separados.
  Miles de componentes × decenas de flags booleanas sería un desperdicio; un bitfield lo resuelve con un
  solo campo.
- **Mapa de propiedades _lazy_ (`property(k, v)`).** Las cosas opcionales (callbacks, skin custom, imagen
  de fondo, estilos alternativos) no son campos fijos — viven en un mapa creado **bajo demanda**. Un
  `Label` simple no paga por un campo de "imagen de fondo" que nunca va a usar.

```java
// property(...) es el "saco de datos" idiomático para lo que es opcional:
comp.property("meuFlag", true);
boolean f = comp.property("meuFlag");   // recupera (nulo si nunca se seteó)
```
Los **estilos** siguen la misma filosofía: se crean bajo demanda a partir del `Skin`, no se instancian
para todo componente de entrada.

## Jerarquía de padre único
Todo `Component` tiene **como máximo un padre**. El árbol de composición es estrictamente jerárquico: añadir
un componente a un container lo elimina de cualquier padre anterior. Esto mantiene el layout y la propagación de
eventos predecibles (cada componente pertenece a exactamente un lugar).

## Qué se deriva de esto
- **Una forma de componer todo:** aprender a montar un panel = saber montar una pantalla.
- **Los layouts son enchufables:** el mismo container cambia de disposición con solo cambiar el `Layout` (base de la
  responsividad — ver [Layout y el modelo Relative](/docs/concepts/the-layout-and-relative-model)).
- **Bajo costo por componente:** bitfield + propiedades lazy es lo que hace viables las listas grandes.

## Ver también
- Aplicar: [Layouts](/docs/ui/layouts) · [Catálogo de componentes](/docs/ui/widgets)
- Siguiente: [El pipeline de renderizado](/docs/concepts/rendering-pipeline)