Problem
A framework's UI primitives are only useful if developers can find them. Today, "what components ship with Grit?" is answered by reading the source. New devs keep re-inventing existing components because they don't know they exist.
Proposal
`grit playground` opens an embedded Storybook (or Ladle / Histoire) at `localhost:6006` showing:
- Every framework UI primitive (CurrencyField, SearchableSelect, DateField, StatusBadge, FilterChips, …) with live editable props
- Design tokens (colours, spacing, type ramp) on one screen with copy-to-clipboard
- Layout primitives (TwoPane, AppShell) demoed with toggles for empty state, loading, error
- Form patterns (drawer + grid + actions) demoed end-to-end
The playground ships separately so it doesn't bloat production builds. Updated stories ship with every framework release.
Why this is differentiating
Mantine, Chakra, Radix all owe their adoption partly to phenomenal docs / playground experiences. A Go framework with a first-class playground is a category-of-one offering.
Acceptance
- `grit playground` works in any Grit app with zero setup
- Every primitive has at least one story
- Design tokens are programmatically exposed (`@grit/tokens`) so apps can override consistently
Problem
A framework's UI primitives are only useful if developers can find them. Today, "what components ship with Grit?" is answered by reading the source. New devs keep re-inventing existing components because they don't know they exist.
Proposal
`grit playground` opens an embedded Storybook (or Ladle / Histoire) at `localhost:6006` showing:
The playground ships separately so it doesn't bloat production builds. Updated stories ship with every framework release.
Why this is differentiating
Mantine, Chakra, Radix all owe their adoption partly to phenomenal docs / playground experiences. A Go framework with a first-class playground is a category-of-one offering.
Acceptance