csf & story writing

11 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Meta and StoryObj imports moved to framework package

In Storybook 9, update story imports from the renderer package to the framework package. Change from `import { Meta, StoryObj } from '{{RENDERER}}'` to `import { Meta, StoryObj } from '{{FRAMEWORK}}'`.

Test utility imports use storybook/test

In Storybook 9, test utilities should be imported from 'storybook/test' instead of '@storybook/test'. For example, import `fn` from 'storybook/test' rather than '@storybook/test'.

Story coverage goals for complete business logic

When writing stories, cover every distinct piece of business logic and state the component can reach, including happy paths, error/edge states, loading states, permissions/roles, empty states, and variations from props/context. Avoid redundant stories that show the same logic.

Provide realistic data and mock network services

Provide realistic props, state, and mocked data in stories. Include meaningful labels/text to make behaviors observable. Stub network/services with deterministic fixtures to keep stories reliable.

Story variants to consider

When picking story variants, consider only those that change behavior: default vs. alternate themes, loading vs. loaded vs. empty vs. error states, validated vs. invalid input, permissions/roles/capabilities, feature flags, and size/density/layout variants that alter logic.

Accessibility in story writing

Use semantic roles/labels in stories and ensure focusable/keyboard interactions are test-covered where relevant.

Clear story naming and structure

Use clear story names that describe the scenario (e.g., 'Error state after failed submit'). Group related variants logically and avoid duplication.

Keep stories minimal with necessary imports

Import Meta/StoryObj from the framework package and test helpers from storybook/test. Keep stories minimal—only include what is needed to demonstrate behavior.

Always provide story links after changes

Always provide story links after any changes to stories files, including changes to existing stories. After changing any UI components, search for related stories that might cover the changes and provide the story links to the user to allow visual inspection of the changes.

Write stories for all components

Always write a Storybook story for any component written. If editing a component, ensure appropriate changes have been made to stories for that component.

Prefer breaking larger components into smaller parts

When writing UI, prefer breaking larger components up into smaller parts.

Give your agent this brain