component-composition

# Component Composition (Atomic Design) ## Overview All web UI follows Atomic Design and a shared component library. The quality bar is reuse and correct placement: a new screen is assembled from existing atoms and molecules, and anything genuinely new is added at the right level so the next screen reuses it too. **Core principle:** Reuse before you build. Before writing any button, card, badge, input, dialog, header, empty-state, or list-row, check the shared library — hand-rolling one that exists is a review-blocking defect. ## The Levels | Level | What | Examples | |-------|------|----------| | **Atom** | Smallest reusable UI, no app logic | Button, Input, Badge, Avatar, Icon | | **Molecule** | A few atoms as a unit | FormField (label+input+error), SearchBar, ListRow | | **Organism** | Section from molecules/atoms | PageHeader, FormDialog, DataTable, EmptyState | | **Template** | Page skeleton/layout, no data | TwoColumnLayout, DetailShell | | **Page** | Route wiring organisms to data/state | ProjectBoardPage | ## Rules - **Reuse the established shared components first** (PageHeader, FormDialog, EmptyState, ConfirmDialog, list rows, etc.). If one almost fits, extend it backward-compatibly — never fork a near-duplicate. - **Place new components at the correct level.** A button is an atom; a card of atoms is a molecule; a page section is an organism. A "component" that fetches data is not a low-level component — split presentation from data. - **Presentation-only belo...