# Tudo é um Component

> A ideia unificadora do CrossFly — só existe Component, e container = Component + Layout.

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

# Tudo é um Component

Esta é a ideia que faz o resto do framework "clicar". No CrossFly **não há uma hierarquia de "widgets"
versus "containers"**. Existe **um** tipo base — `Component` — e qualquer `Component` vira um
container no momento em que recebe um `Layout`.

## `container = Component + Layout`
```java
Component painel = new Component();       // um Component "vazio"
painel.setLayout(new VerticalLayout());   // agora ele organiza filhos → é um container
painel.add(LAY_AUTO, new Label("Título"));
painel.add(LAY_FILL, new ListView<>(...));
```
Um `Button` é um `Component`. Um `Label` é um `Component`. Uma `Window` (tela) é um `Component` de tela
cheia. **Não existe uma classe `Container` especial** — a "capacidade de conter" é só ter um `Layout`.
Isso significa que você compõe telas do mesmo jeito, sempre, do botão ao app inteiro.

## Por que a classe base é desenhada assim
`Component` precisa escalar para **milhares de instâncias** sem explodir a memória. Duas decisões-chave:

- **Bitfield (`cbits`) em vez de dezenas de `boolean`.** Estados como *enabled*, *visible*, *focused*,
  *pressed*, *tem layout*, *tem estilo focado*… são bits de um único inteiro long, não campos separados.
  Milhares de componentes × dezenas de flags booleanas seria desperdício; um bitfield resolve com um
  campo só.
- **Mapa de propriedades _lazy_ (`property(k, v)`).** Coisas opcionais (callbacks, skin custom, imagem
  de fundo, estilos alternativos) não são campos fixos — vivem num mapa criado **sob demanda**. Um
  `Label` simples não paga por um campo de "imagem de fundo" que nunca vai usar.

```java
// property(...) é o "saco de dados" idiomático para o que é opcional:
comp.property("meuFlag", true);
boolean f = comp.property("meuFlag");   // recupera (nulo se nunca setado)
```
Os **estilos** seguem a mesma filosofia: são criados sob demanda a partir do `Skin`, não instanciados
para todo componente na largada.

## Hierarquia de pai único
Todo `Component` tem **no máximo um pai**. A árvore de composição é estritamente hierárquica: adicionar
um componente a um container o remove de qualquer pai anterior. Isso mantém o layout e a propagação de
eventos previsíveis (cada componente pertence a exatamente um lugar).

## O que decorre disso
- **Uma forma de compor tudo:** aprender a montar um painel = saber montar uma tela.
- **Layouts são plugáveis:** o mesmo container muda de arranjo só trocando o `Layout` (base da
  responsividade — ver [Layout e o modelo Relative](/docs/concepts/the-layout-and-relative-model)).
- **Custo baixo por componente:** bitfield + propriedades lazy é o que torna listas grandes viáveis.

## Veja também
- Aplicar: [Layouts](/docs/ui/layouts) · [Catálogo de componentes](/docs/ui/widgets)
- Próximo: [O pipeline de renderização](/docs/concepts/rendering-pipeline)