# सब कुछ एक Component है

> CrossFly का एकीकृत विचार — केवल Component मौजूद है, और container = Component + Layout।

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

# सब कुछ एक Component है

यही वह विचार है जो बाकी फ्रेमवर्क को समझ में आने लायक बनाता है। CrossFly में **"widgets" बनाम "containers" जैसी
कोई पदानुक्रमिकता नहीं है**। **एक ही** आधार प्रकार है — `Component` — और कोई भी `Component` उसी क्षण container
बन जाता है जब उसे एक `Layout` मिलता है।

## `container = Component + Layout`
```java
Component painel = new Component();       // एक "खाली" Component
painel.setLayout(new VerticalLayout());   // अब यह children को व्यवस्थित करता है → यह एक container है
painel.add(LAY_AUTO, new Label("Título"));
painel.add(LAY_FILL, new ListView<>(...));
```
एक `Button` एक `Component` है। एक `Label` एक `Component` है। एक `Window` (स्क्रीन) एक पूर्ण-स्क्रीन `Component`
है। **कोई विशेष `Container` क्लास मौजूद नहीं है** — "समाहित करने की क्षमता" बस एक `Layout` होने भर से है।
इसका मतलब है कि आप स्क्रीनों को हमेशा एक ही तरीके से जोड़ते हैं, बटन से लेकर पूरे app तक।

## आधार क्लास को इस तरह क्यों डिज़ाइन किया गया है
`Component` को मेमोरी फुलाए बिना **हज़ारों इंस्टैंस** तक स्केल करना पड़ता है। दो प्रमुख निर्णय:

- **दर्जनों `boolean` के बजाय Bitfield (`cbits`)।** *enabled*, *visible*, *focused*, *pressed*, *layout है*,
  *focused स्टाइल है*… जैसी अवस्थाएँ एक अकेले long पूर्णांक के बिट्स हैं, अलग-अलग फ़ील्ड नहीं। हज़ारों कंपोनेंट ×
  दर्जनों boolean फ़्लैग बर्बादी होती; एक bitfield इसे एक ही फ़ील्ड से हल कर देता है।
- **_Lazy_ प्रॉपर्टी मैप (`property(k, v)`)।** वैकल्पिक चीज़ें (callbacks, कस्टम skin, पृष्ठभूमि की छवि,
  वैकल्पिक स्टाइल) निश्चित फ़ील्ड नहीं हैं — वे एक मैप में रहती हैं जो **माँग पर** बनाया जाता है। एक साधारण
  `Label` किसी "पृष्ठभूमि छवि" फ़ील्ड की कीमत नहीं चुकाता जिसका वह कभी उपयोग नहीं करेगा।

```java
// property(...) वैकल्पिक चीज़ों के लिए मुहावरेदार "डेटा थैला" है:
comp.property("meuFlag", true);
boolean f = comp.property("meuFlag");   // पुनः प्राप्त करता है (यदि कभी सेट नहीं हुआ तो null)
```
**स्टाइल** भी उसी दर्शन का पालन करते हैं: वे `Skin` से माँग पर बनाए जाते हैं, हर कंपोनेंट के लिए शुरुआत में ही
इंस्टैंशिएट नहीं किए जाते।

## एकल-अभिभावक पदानुक्रम
हर `Component` का **अधिक-से-अधिक एक ही अभिभावक** होता है। रचना का वृक्ष सख्ती से पदानुक्रमिक है: किसी कंपोनेंट
को किसी container में जोड़ना उसे उसके किसी भी पिछले अभिभावक से हटा देता है। यह layout और events के प्रसार को
पूर्वानुमेय बनाए रखता है (हर कंपोनेंट ठीक एक ही जगह का होता है)।

## इससे क्या निकलता है
- **सब कुछ जोड़ने का एक ही तरीका:** एक पैनल बनाना सीखना = एक स्क्रीन बनाना जानना।
- **Layouts प्लग करने योग्य हैं:** वही container केवल `Layout` बदलने से व्यवस्था बदल लेता है (उत्तरदायित्व का
  आधार — देखें [Layout और Relative मॉडल](/docs/concepts/the-layout-and-relative-model))।
- **प्रति कंपोनेंट कम लागत:** bitfield + lazy प्रॉपर्टीज़ ही वह है जो बड़ी सूचियों को व्यवहार्य बनाता है।

## यह भी देखें
- लागू करें: [Layouts](/docs/ui/layouts) · [कंपोनेंट की सूची](/docs/ui/widgets)
- आगे: [रेंडरिंग पाइपलाइन](/docs/concepts/rendering-pipeline)