Component System
Reusable UI primitives stay separate from product-owned screens so the interface can evolve without mixing responsibilities.
On this page
| Area | Use it for | Avoid |
|---|---|---|
| components/ui | Buttons, inputs, dialogs, popovers, tabs, cards, badges, state blocks, and primitives reused across domains. | Do not put billing, content, customer, or admin business rules here. |
| components/landing | Landing-page sections and marketing-specific visuals. | Do not import route-specific data access or dashboard-only logic. |
| components/providers | App providers such as theme, Supabase, page transitions, and shared client wrappers. | Do not hide feature orchestration inside generic providers. |
| components/uploads | Reusable media upload UI used by branding and content work. | Keep file validation and storage rules behind server-safe helpers. |
| features/<domain>/ui | Screens, forms, panels, and views owned by one product domain. | Do not move domain UI into global components until multiple domains actually need it. |
Reusable UI rules
- Use existing primitives before creating a new pattern.
- Keep props explicit and domain-neutral in components/ui.
- Keep product copy and domain-specific state in feature UI.
- Prefer one focused component over a generic component that hides business meaning.