Storybook · Writing and testing · all subjects

pages

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.

Pure presentational pages in Storybook

Teams at the BBC, The Guardian, and the Storybook maintainers build pure presentational pages in Storybook. In this approach, you do not need to do anything special to render your pages. All the messy connected logic is done in a single wrapper component in your app outside of Storybook.

Pure presentational pages: benefits

Pure presentational pages have two main benefits: it is easy to write stories once components are in this form, and all the data for the story is encoded in the args of the story, which works well with other parts of Storybook's tooling such as controls.

Pure presentational pages: downsides

Pure presentational pages have three main downsides: your existing app may not be structured in this way and may be difficult to change; fetching data in one place means you need to drill it down to the components that use it, which can be less appropriate for some data fetching approaches; and it is less flexible if you want to load data incrementally in different places on the screen.

Connected components definition

Connected components are components that depend on external data or services. For example, a full page component is often a connected component. When you render a connected component in Storybook, you need to mock the data or modules that the component depends on.

Mocking layers for connected components

There are various layers in which you can mock connected components in Storybook: mocking imports of modules (from external packages or internal to your project), mocking API services for network requests to REST or GraphQL APIs, and mocking providers that supply data or configuration through context.

Container and presentational component split pattern

It is possible to avoid mocking dependencies of connected container components by passing them around via props or React context. This requires a strict split of the container and presentational component logic. If a component is responsible for both data fetching logic and rendering DOM, it will need to be mocked as described elsewhere.

React context for container components pattern

A solution to avoid mocking container components is to create a React context that provides the container components. This allows you to freely embed container components at any level in the component hierarchy without worrying about mocking their dependencies, since you can swap out the containers themselves with their mocked presentational counterpart in Storybook.

ProfilePageContext file structure pattern

When using a container context pattern, it is recommended to divide context containers up over specific pages or views. For example, for a ProfilePage component, the file structure should include: ProfilePage.js, ProfilePage.stories.js, ProfilePageContainer.js, and ProfilePageContext.js.

Global container context pattern

It is often helpful to set up a global container context, perhaps named GlobalContainerContext, for container components that may be rendered on every page of your app, and add them to the top level of your application. While it is possible to place every container within this global context, it should only provide globally required containers.

Mocking containers in Storybook with context

In the context of Storybook, instead of providing container components through context, you provide their mocked counterparts. In most cases, the mocked versions of these components can often be borrowed directly from their associated stories.

Providing containers to application with context provider

In the context of your application, you need to provide a presentational component with all of the container components it requires by wrapping it with the context provider. For example, in Next.js, this would be your pages/profile.js component.

Give your agent this brain