The Problem
Only 26 of roughly 97 UI components (27%) had Storybook stories. This made it impossible to visually review, manually test, or track UI-related ad-hoc tasks across the design system. Components without stories were invisible to the Storybook-driven review workflow. If I could not see a component in isolation, I could not verify whether it was using design tokens correctly or whether it handled its visual states properly.
What I Built
I wrote .stories.svelte files for all 107 components that lacked stories, organised into 9 domain-based phases. Every new story uses Svelte CSF format (not .stories.ts) because the TypeScript format crashes with a "snippet2 is not a function" error for components that use Svelte 5 snippet children.
Phases S1-S2: Foundation. Atoms (Toggle, RangeSlider, admin modals) and layouts (Center, Container, Stack, Inline, Grid, PageSection, PageFrame, PageLayout, MainLayout, AdminPageLayout, Footer, Header, ThemeContext). These are the primitives everything else composes on.
Phases S3-S4: Forms and interaction. Form fields (DateField, FileField, JsonField, SelectField), ConfigPanel, ErrorPage, cards (SolutionCard), headers (AdminPageHeader), navigation (AdminNavUser, AdminNavMain, BackLink), and sections (LogoBar, TestimonialsSection, ProseSection, AlternativeContact, CtaButtonGroup).
Phases S5-S6: Chat system. The entire chat system from atoms up: BouncingDots, ChatMessage, ChatInput, ChatContainer, InlineAuthForm, VisitorForm, plus all response types (ChatField, ChatSubmitButton, ChoiceResponse, InputResponse, AuthResponse, SignupResponse). These needed careful prop mocking to simulate message flows.
Phases S7-S8: Admin and content. All admin components including the collection browser, pagination, detail views, login form, documentation components (CodeBlock, ComponentPreview, PropsTable, TokenSwatch), and settings panels (ColourPicker, FeatureToggle, ImageUpload, SettingField, SettingsSection). Plus content components: TechStackSidebar, ArticleShareLine, ArticleSidebar, TableOfContents, ArticleHero.
Phase S9: Visual and specialist. The widget system (FloatingPill, Location, ScrollingText, Spotify, WidgetWrapper, Duolingo, WidgetBar, WidgetTray, HeroChatInput), backgrounds (BackgroundSurface, StickyChartBackground, CausticEnvironment, MaterialEngineFilters, IridescentObject), D3 charts (BarChart, LineChart), calendar and pickers, assets (Wordmark, Logo, InlineSvg), all 8 illustration components, the Spotify playlist demo components, and skeletons/SEO.
Key Decisions
- Svelte CSF only for all new stories -- the
.stories.tsformat has a known crash with snippet children. - Always use asChild when a story body renders the meta component manually -- prevents triple-nested DOM elements.
- Mock PocketBase via props rather than mocking the SDK -- components receive data from server load functions, not direct SDK calls.
- Static D3 datasets for chart stories -- avoids network mocking while still rendering meaningful charts.
- Group by domain, not alphabetically -- each phase produces a coherent Storybook section that can be reviewed as a unit.
What is Next
With 100% story coverage, every component is now visible for visual review and design token compliance checks. The immediate follow-up was the design system cleanup phase, which used Storybook as its primary verification tool to catch hardcoded colours, unused tokens, and inconsistent styling across the full component set.