# Atomic Component Library
This codebase follows the **Atomic Design** methodology to organize UI components into a scalable, maintainable structure.
## Structure Overview
```
src/components/
├── atoms/ # Basic building blocks (smallest components)
├── molecules/ # Simple combinations of atoms
├── organisms/ # Complex components built from molecules and atoms
├── ui/ # shadcn base components
└── [features]/ # Feature-specific complex components
```
## Hierarchy Explained
### 🧪 Atoms (`/atoms`)
**Purpose**: The smallest, most fundamental UI elements that cannot be broken down further.
**Characteristics**:
- Single-purpose components
- No business logic
- Highly reusable
- Accept minimal props
- No dependencies on other custom components (may use shadcn)
**Examples**:
- `AppLogo` - The application logo icon
- `TabIcon` - Icon wrapper with styling variants
- `StatusIcon` - Status indicator icons (saved, synced)
- `ErrorBadge` - Badge showing error count
**When to create an atom**:
- You have a single UI element used in multiple places
- The component has no complex logic or state
- It's a styled wrapper around a basic HTML element or icon
---
### 🔬 Molecules (`/molecules`)
**Purpose**: Simple combinations of atoms that work together as a unit.
**Characteristics**:
- Composed of 2-5 atoms
- Single responsibility
- Minimal state management
- Reusable across multiple contexts
- May include simple interactions
**Examples**:
- `SaveIndicator` - Combines StatusIcon + text to show save status
- `AppBranding` - Combines AppLogo + title + subtitle
- `PageHeaderContent` - Combines TabIcon + title + description
- `ToolbarButton` - Button + Tooltip wrapper
- `NavigationItem` - Icon + label + badge navigation button
- `NavigationGroupHeader` - Collapsible group header with count
**When to create a molecule**:
- You're combining atoms to create a meaningful UI pattern
- The combination is reused in multiple organisms
- It represents a single functional unit (like "branding" or "save status")
---
### 🧬 Organisms (`/organisms`)
**Purpose**: Complex, feature-rich components that combine molecules and atoms.
**Characteristics**:
- Complex composition (5+ child components)
- May manage state
- Business logic allowed
- Feature-specific functionality
- Can include API calls or data fetching
**Examples**:
- `NavigationMenu` - Full sidebar navigation with groups, items, search
- `PageHeader` - Complete page header with icon and description
- `ToolbarActions` - Toolbar with multiple action buttons
- `AppHeader` - Complete application header with nav, branding, save indicator, and actions
**When to create an organism**:
- You're building a major UI section (header, navigation, toolbar)
- The component manages complex state or user interactions
- It coordinates multiple molecules and atoms
- It's feature-specific rather than generic
---
### 🏗️ Feature Components (`/components/[FeatureName].tsx`)
**Purpose**: Full-featured, domain-specific components that implement complete features.
**Characteristics**:
- High-level business components
- Complete feature implementations
- May use multiple organisms, molecules, and atoms
- Include complex state management
- Feature-specific (not reusable across features)
**Examples**:
- `CodeEditor` - Full Monaco code editor with file management
- `ModelDesigner` - Complete Prisma model design interface
- `ComponentTreeBuilder` - React component hierarchy builder
- `WorkflowDesigner` - Visual workflow design canvas
- `ProjectDashboard` - Complete dashboard view
**When to create a feature component**:
- You're implementing a complete feature or page
- The component is not reusable outside its feature domain
- It requires significant state management and business logic
---
## Component Organization Rules
### 1. Import Hierarchy
Components should only import from their level or below:
- ✅ Organisms can import molecules and atoms
- ✅ Molecules can import atoms
- ❌ Atoms should NOT import molecules or organisms
- ❌ Molecules should NOT import organisms
### 2. Naming Conventions
- **Atoms**: Simple nouns (`AppLogo`, `StatusIcon`, `ErrorBadge`)
- **Molecules**: Descriptive combinations (`SaveIndicator`, `ToolbarButton`, `NavigationItem`)
- **Organisms**: Feature-descriptive (`NavigationMenu`, `AppHeader`, `ToolbarActions`)
- **Features**: Feature names (`CodeEditor`, `ModelDesigner`, `ProjectDashboard`)
### 3. File Structure
Each atomic level has:
```
atoms/
├── AppLogo.tsx
├── TabIcon.tsx
├── StatusIcon.tsx
├── ErrorBadge.tsx
└── index.ts # Exports all atoms
```
### 4. Index Files
Each directory should have an `index.ts` for clean imports:
```typescript
// atoms/index.ts
export { AppLogo } from './AppLogo'
export { TabIcon } from './TabIcon'
export { StatusIcon } from './StatusIcon'
export { ErrorBadge } from './ErrorBadge'
```
This allows:
```typescript
// Good ✅
import { AppLogo, StatusIcon } from '@/components/atoms'
// Instead of ❌
import { AppLogo } from '@/components/atoms/AppLogo'
import { StatusIcon } from '@/components/atoms/StatusIcon'
```
---
## Configuration Files
### `lib/navigation-config.tsx`
Centralized configuration for navigation structure:
- **`tabInfo`**: Maps tab IDs to their display information
- **`navigationGroups`**: Defines navigation hierarchy and groupings
- **`NavigationItemData`**: TypeScript interfaces for type safety
**Benefits**:
- Single source of truth for navigation
- Easy to add/remove navigation items
- Type-safe navigation configuration
- Separates data from presentation logic
---
## Migration Guide
When refactoring existing components:
1. **Identify the component's level**
- Does it contain business logic? → Feature component
- Does it combine many elements? → Organism
- Does it combine a few atoms? → Molecule
- Is it a single UI element? → Atom
2. **Check dependencies**
- What does it import?
- Can it be broken into smaller pieces?
- Are parts reusable elsewhere?
3. **Extract reusable parts**
```typescript
// Before: Monolithic component
function Header() {
return (