ADRs
0026, Atomic design in Canvas
Why Canvas organizes components as atoms, molecules, organisms, charts
Status: Accepted Date: 2026-02 Stakeholders: Bobby Nannier
Context
The Canvas design system has 105 components used across Athena, Hera, and Site. Without a hierarchy, navigation is overwhelming.
Decision
Brad Frost's atomic design taxonomy with one Canvas-specific addition:
| Tier | Examples | Purpose |
|---|---|---|
| Atoms | Button, Input, Label, Icon, Badge | Indivisible primitives. |
| Molecules | FormField, Card, Tabs, Tooltip | Combinations of atoms. |
| Organisms | DataTable, Modal, Sidebar, NavBar | Complete sections. |
| Charts | LineChart, PieChart, WorldHeatMap | Data visualisation wrappers (Nivo / Leaflet). |
Directory layout matches:
canvas/src/components/
├── atoms/ (22 components)
├── molecules/ (35)
├── organisms/ (28)
└── charts/ (20)Imports follow the layout:
import { Button } from "@olympusoss/canvas/atoms";
import { DataTable } from "@olympusoss/canvas/organisms";Consequences
- Discoverability. Engineers ask "is this an atom or a molecule?" and find the right place.
- Composition pressure. Building a new component forces the question "what tier is this?", usually clarifying the right abstraction.
- Charts get their own tier. Charts have different concerns (data binding, axis configuration) than typical UI, so a dedicated bucket avoids forcing them into "organisms."
Where it gets blurry
- Tooltip could be molecule or atom. We placed it in molecules because it wraps an atom.
- Dropdown / Select has internal state and presents options, molecule, even though feels organism-y.
When in doubt, the more granular tier wins.
Related
- Canvas docs, full component playground.
- Repo map, Canvas
- ADR 0012, Source-only NPM packages