Component Hierarchy
The complete hierarchy of components from Business to primitives
Component Hierarchy
Business Hierarchy
Business (or Startup extends Business)
├── Site (public/marketing)
│ └── Site → Page → Section → Component
└── App (authenticated/dashboard)
└── App → View → Panel → ComponentInheritance Model
Components can be defined at any level of the hierarchy. When a Business has certain capabilities (like an API), it automatically gets corresponding components:
Business with <API/>
├── Site gets:
│ ├── LandingPage
│ ├── Docs
│ ├── API (reference)
│ ├── SDK (downloads)
│ └── Blog
└── App gets:
└── DeveloperDashboard
├── Overview
├── Keys
├── Webhooks
├── Requests (usage)
└── LogsSite Hierarchy
Site → Page → Section → Component
Level 1: Site
The root container. Provides theme, layout shell, and global context.
| Component | Description | Payload Collection |
|---|---|---|
<Site> | Root wrapper with theme/providers | sites |
Level 2: Page
Full-page layouts that compose sections.
| Component | Description | Payload Collection |
|---|---|---|
<LandingPage> | Homepage with hero, features, etc. | pages (type: landing) |
<Page> | Generic content page | pages |
<BlogPage> | Blog listing page | blogs |
<BlogPostPage> | Single blog post | posts |
<DocsPage> | Documentation page | docs |
<APIPage> | API reference page | apis |
<SDKPage> | SDK documentation | sdks |
<PricingPage> | Pricing page | prices |
<ContactPage> | Contact/demo request | - |
<LegalPage> | Terms, privacy, etc. | pages (type: legal) |
Level 3: Section
Page sections that compose components.
| Component | Description | Auto-wires to |
|---|---|---|
<Hero> | Hero section with CTA | - |
<Features> | Features grid/bento | features |
<Pricing> | Pricing tiers | prices |
<Testimonials> | Customer quotes | - |
<FAQ> | FAQ accordion | - |
<CTA> | Call-to-action banner | - |
<Stats> | Statistics/metrics | - |
<Team> | Team members | - |
<Logos> | Customer/partner logos | - |
<Comparison> | Competitor comparison | competitors |
<Changelog> | Release notes | - |
Level 4: Component
Primitive UI components (from @mdxui/primitives).
App Hierarchy
App → View → Panel → Component
Level 1: App
The root container. Provides auth, theme, and global context.
| Component | Description | Payload Collection |
|---|---|---|
<App> | Root wrapper with auth/providers | apps |
Level 2: View
Full-page views (routes) within the app shell.
| Component | Description | Auto-wires to |
|---|---|---|
<Dashboard> | Main dashboard/overview | - |
<SettingsView> | Settings page shell | - |
<TeamView> | Team management | members |
<BillingView> | Billing management | subscriptions |
<KeysView> | API key management | apiKeys |
<WebhooksView> | Webhook management | webhooks |
<RequestsView> | Usage/request logs | usageRecords |
<DatabaseView> | Database explorer | varies |
<IntegrationsView> | Integration management | integrations |
<VaultView> | Secrets management | - |
Level 3: Panel
Panels within views (sidebars, detail panels, etc.)
| Component | Description |
|---|---|
<Sidebar> | Navigation sidebar |
<Header> | Top header bar |
<DetailPanel> | Side detail panel |
<ActivityPanel> | Activity feed |
<FilterPanel> | Filter controls |
Level 4: Component
Primitive UI components (from @mdxui/primitives).
Widgets
Widgets are Views or Panels rendered in overlay contexts:
| Widget | Context | Description |
|---|---|---|
<SearchBox> | Modal | Global search |
<ChatBox> | Slideover | Chat interface |
<Editor> | Slideover/Modal | MDX editor |
<CommandPalette> | Modal | Command palette |
<Notifications> | Popup | Notification center |
Widget Contexts
type WidgetContext = 'modal' | 'slideover' | 'popup' | 'inline'
interface WidgetProps {
context?: WidgetContext
trigger?: ReactNode // What opens the widget
open?: boolean // Controlled state
onOpenChange?: (open: boolean) => void
}Component Type Registry
Every component at every level can have a type that determines its behavior:
// Site types determine default pages/sections
type SiteType =
| 'marketing' // LandingPage, Features, Pricing, Blog
| 'documentation' // Docs, API Reference, SDK
| 'blog' // Blog, Posts
| 'directory' // Listings, Search
// App types determine default views
type AppType =
| 'dashboard' // Overview, Analytics
| 'developer' // Keys, Webhooks, Requests, Logs
| 'admin' // Users, Settings, Database
| 'saas' // Dashboard + Billing + TeamPayload Collection Mapping
| Level | Component | Collection | Key Fields |
|---|---|---|---|
| Business | <Business> | businesses | name, org |
| Business | <Startup> | startups | name, stage, business |
| Site | <Site> | sites | name, template, domains |
| Page | <Page> | pages | name, slug, site, template |
| Page | <BlogPage> | blogs | name, site |
| Page | <DocsPage> | docs | name, project |
| App | <App> | apps | name, template, apis, sdks |
| Feature | <API> | apis | name, slug, domain, business |
| Feature | <SDK> | sdks | name, api, language |
Next Steps
- Define exact props for each component level
- Map existing UI components to this hierarchy
- Create missing components
- Implement auto-wiring logic in workers