Using decorators for context in Storybook
If the same context applies to all stories of a component, you can use a decorator to provide that context rather than setting it up in each individual story.
Storybook · Writing and testing · all subjects
decorators
19 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
Mocking global containers with decorator in preview.js
If you have set up GlobalContainerContext, you need to set up a decorator within Storybook's preview.js to provide context to all stories.
What is a decorator
A decorator is a way to wrap a story in extra rendering functionality. Many addons define decorators to augment stories with extra rendering or gather details about how a story renders. When writing stories, decorators are typically used to wrap stories with extra markup or context mocking.
Story context properties
The second argument to a decorator function is the story context, which is an object containing: args (the story arguments), argTypes (Storybook's argTypes for customizing args), globals (Storybook-wide globals), hooks (Storybook's API hooks like useArgs and useGlobals), parameters (the story's static metadata), and viewMode (Storybook's current active window such as canvas or docs).
Using story context in decorators
The story context passed to decorators can be used to adjust the behavior of a decorator based on the story's arguments or other metadata. For example, you can create a decorator that applies a layout to the story by checking parameters.pageLayout which can be set to values like 'page' or 'page-mobile'.
Story decorators definition
To define a decorator for a single story, use the decorators key on a named export in the story file.
Component decorators definition
To define a decorator for all stories of a component, use the decorators key of the default CSF export in the story file.
Global decorators definition
To set a decorator for all stories, use the decorators export in the .storybook/preview.ts or preview.tsx file.
Decorator inheritance order
All decorators relevant to a story run in a specific order: first global decorators in the order they are defined, then component decorators in the order they are defined, then story decorators in the order they are defined, starting from the innermost decorator and working outwards and up the hierarchy in the same order.
Decorators for wrapping with extra markup
Decorators can be used to wrap stories with extra markup or provide harnesses for components that require it. For example, if a component runs right up to its edges, you can use a decorator to add spacing inside Storybook.
Decorators for providing mocked data
Decorators can be used to provide mocked data for connected components that require side-loaded data to render, without having to refactor the components to accept that data as an arg.
Pure rendering with decorators
It is useful to ensure that a story remains a pure rendering of the component under test, with any extra HTML or components used only as decorators. This practice works best with features like the Source Doc Block.
Storybook hooks in decorators
When using Storybook hooks like useArgs and useGlobals in decorators alongside framework hooks (such as React's useState and useEffect), use Storybook's hook equivalents from storybook/preview-api instead to avoid errors on re-render.
Decorators definition
Decorators are a mechanism to wrap a component in arbitrary markup when rendering a story. Components are often created with assumptions about where they render, and decorators can provide necessary theme or layout wrappers, context providers, or other required elements.
Decorators configuration levels
You can configure decorators at the story, component, and global levels. Decorators can also be provided by addons.
Mocking providers with decorators
To mock a provider, wrap your component in a decorator that includes the necessary context. This applies to renderers that use JSX, such as React and Solid. Components can receive data or configuration from context providers like ThemeProvider or Redux providers, and decorators can intercept and mock these providers.
Preview file must support JSX for mocking providers
When mocking providers using decorators, the preview file extension must be adjusted to allow JSX. Use `.tsx` or `.jsx` file extensions depending on your project's settings to enable JSX in the preview file.
Access story parameters in decorator context for configurable mocking
To configure mock providers differently for individual stories, use the decorator function's second 'context' argument to access the story's parameters. This allows you to read parameters like 'parameters.theme' and adjust the provided value accordingly, enabling flexible and maintainable provider mocking without repetition.
Parameterized provider mocking pattern
Define a provider decorator once that reads from story parameters, then define different parameter values in individual stories to adjust the provider's value. This approach allows testing components with different themes, user roles, or mock data without duplicating the decorator definition for each story.