diff --git a/.agents/context/decisions/005-component-documentation-strategy.md b/.agents/context/decisions/005-component-documentation-strategy.md new file mode 100644 index 0000000..8155b4f --- /dev/null +++ b/.agents/context/decisions/005-component-documentation-strategy.md @@ -0,0 +1,394 @@ +# ADR-005: Component Documentation and Preview Strategy + +## Status + +**Accepted** - January 2025 + +## Context + +To improve the documentation experience and align with industry standards (shadcn/ui, prompt-kit), we evaluated multiple approaches for: + +1. How to access component source code for "Code" tabs +2. How to structure documentation pages +3. How to render component previews +4. How to document component props/API + +This decision follows research documented in `.agents/context/research/prompt-kit-component-page-analysis.md`. + +--- + +## Decision 1: Source Code Access Strategy + +### Selected: Option A (filesystem) + Option B (registry.json) hybrid + +**Approach:** +- **Docs site**: Read source files from filesystem at build time using `fs.readFileSync` +- **Registry distribution**: Embed source in generated JSON files for shadcn CLI + +```typescript +// lib/code.ts - For docs site +import fs from "fs" +import { cache } from "react" + +export const extractCodeFromFilePath = cache((filePath: string) => { + return fs.readFileSync(filePath, "utf-8") +}) +``` + +### Rationale + +| Consideration | Analysis | +|---------------|----------| +| **Prompt-kit precedent** | Uses filesystem reads for docs - proven, simple | +| **shadcn/ui precedent** | Embeds source in registry JSON for CLI distribution | +| **Maintenance** | Filesystem reads always reflect actual code (no drift) | +| **Performance** | React cache + static generation = fast | +| **Monorepo fit** | Works well - read from `packages/ui/src/components/` | + +### Alternatives Rejected + +- **Fetch from GitHub raw URLs**: Network dependency, rate limiting, slower +- **Registry.json only**: Bloats JSON, harder to maintain, can drift + +--- + +## Decision 2: Documentation Format + +### Selected: Option A (MDX-based docs) + +**Approach:** +- Use MDX files for component documentation +- Each component gets a dedicated MDX file with examples, usage, and API reference +- Custom MDX components for Preview/Code tabs, API tables + +``` +apps/www/src/app/docs/ +├── usage-meter/ +│ ├── page.mdx # Main documentation +│ ├── usage-meter-basic.tsx # Example variant +│ └── usage-meter-advanced.tsx # Example variant +``` + +### Rationale + +| Consideration | Analysis | +|---------------|----------| +| **Industry standard** | shadcn/ui, Radix, prompt-kit, Chakra all use MDX | +| **Rich content** | Supports prose, callouts, warnings, custom components | +| **SEO** | Static content is better for search engines | +| **Flexibility** | Mix markdown prose with React components | +| **Scalability** | Well-suited for growing component libraries | + +### Alternatives Rejected + +- **Dynamic routes only**: Less flexible, harder to write custom prose +- **Hybrid**: Two systems create confusion about where content lives + +### Migration Note + +Current implementation uses dynamic `[name]/page.tsx` routes. Migration path: +1. Set up MDX infrastructure (@mdx-js/loader, mdx-components.tsx) +2. Create MDX templates for new components +3. Gradually migrate existing component pages + +--- + +## Decision 3: Preview Rendering Strategy + +### Selected: Option C (Hybrid) + +**Approach:** +- **Blocks** (full-page layouts): Render in iframe for complete isolation +- **UI components** (buttons, meters, cards): Render directly in the page + +```tsx +const isBlock = component.type === "registry:block" + +return isBlock ? ( +