What is Storybook: A Complete UI Components Guide 

A growing number of UI components and too many variations, paired with inconsistent designs where new features use different variations of existing components, add unnecessary complexity to projects. Frontend developers struggle to determine the correct styling and appropriate behaviour of UI components they need to implement for new features.  That’s a common scenario for many […]

by Penko Atanasov

February 16, 2024

5 min read

What is Storybook Image by Freepik

A growing number of UI components and too many variations, paired with inconsistent designs where new features use different variations of existing components, add unnecessary complexity to projects. Frontend developers struggle to determine the correct styling and appropriate behaviour of UI components they need to implement for new features. 

That’s a common scenario for many projects – with the introduction of new features, they try to also introduce new variants of existing components. This leads to a lack of a source of truth, which ultimately leads to inconsistencies on the front end. This problem also impacts the works of QA analysts – making it more difficult to determine which is the “correct” version of a particular component. Subsequently, this leads to slower development and testing processes.

What is Storybook

Storybook aims to solve the above-mentioned problem. It’s no longer necessary to build and deploy a whole application and navigate to a specific page to test out components and check how they interact. Instead, they can be tested in isolation without being coupled with any business logic. Storybook allows developers to focus on each variation of a component where each variation is linked to a story. Stories contain the necessary props and mock data required to simulate a component variation. The result is a directory of UI components and their stories, where each of them contains the necessary documentation required to understand how the component works.

Storybook lets you use controls which can change a component’s arguments dynamically without needing to write additional complex code. There are multiple options, including radio buttons, select dropdown, text fields and even date pickers and many others.

Example Use Cases

A great example of Storybook’s use case is to show what an Alert / Toast component would look like. Typically, when an action is performed on the front end, the user receives some sort of feedback in the form of an Alert or Toast. 

image 14 - What is Storybook: A Complete UI Components Guide 

Figure 1

However, there could be multiple variants associated with different states such as error, success and warning, as demonstrated in Figure 2. Figures 1 and 2 show the documentation page, specifying the props and their correct types. The user can control what’s displayed in the Alert as seen in Figure 1.

image 11 - What is Storybook: A Complete UI Components Guide 

Figure 2

The component is built in React, using the Material UI library. The meta-object specifies the component to show on the UI and where the story goes in the list. The meta also describes the argument types, which refer to the component props and can be disabled individually in the table as desired (see Figure 1).  As you have probably guessed, the components can be grouped together into different categories. 

const meta: Meta<typeof Alert> = {
  // Add 'Alert' component to 'Components' category
    title: "Components/Alert",
  // Select component to display
    component: Alert,
  // argTypes refer component props
  argTypes: {
        children: {
            control: "text",
            description: "The text to display in the alert",
            table: {
                type: { summary: "ReactNode" },
                defaultValue: { summary: undefined },
            },
        },
        onClose: {
            action: "onClose",
            description: "The function to call when the alert is closed",
        },
        ref: { table: { disable: true } },
        component: { table: { disable: true } },
    },
    args: {
        children: "Testing text for an Alert",
    },
};

export default meta;

Each story export represents a different alert state, which can be confirmed on the UI. The default arguments can be overridden for each story, and event custom controls can be implemented, which can be demonstrated in another example.

type Story = StoryObj<typeof Alert>;

// Each export is displayed as a story
export const Default: Story = {};

export const Info: Story = {
    render: (args) => <Alert.Info {...args} />,
};

export const Warning: Story = {
    render: (args) => <Alert.Warning {...args} />,
};

export const Error: Story = {
    render: (args) => <Alert.Error {...args} />,
};

export const Success: Story = {
    render: (args) => <Alert.Success {...args} />,
};

Font icons are a common necessity for web applications – and another great use case for Storybook is to display a collection of them. As seen in the following code sample, choosing the correct font icon can be difficult. As such, creating a story that displays a gallery of all icons (how they look on the UI and their names) can significantly simplify the process of identifying the desired icon.

// Example implementation of the icon component where the icon prop is a string

// and relates to specific font icon

<Icon icon="FaArrowUp"/>
image 12 - What is Storybook: A Complete UI Components Guide 

Figure 3

Benefits

Share Storybook with your team

You can deploy Storybook separately from your app, for everyone in the team to view as the single source of truth for the UI. This can be useful for designers when creating new designs and checking against Storybook for existing components, ensuring consistency is kept. It’s also beneficial for developers to check if required components are already available in Storybook when implementing new features and refactoring/refreshing existing ones. Similarly, QAs can spend less time figuring out if the UI has the correct components implemented, and they can spot component-related bugs even before integrating them into new features. The developers can then fix the issue in the common component, thus fixing it in all used places across the app if it has already been used.

Little overhead

Writing stories for common UI components doesn’t require too much effort. The minimum work required is to import the components and define controls for their various props. Unlike other practices, such as writing unit tests and automation tests, writing simple stories requires very little effort.

Test UIs

Furthermore, it’s even possible to use stories to write tests (similarly to traditional unit tests) using a library such as React Testing Library. Because stories are written as ES6 modules, they can be reused to simulate browser-based interaction tests. Compared to unit tests, it’s possible to test the “happy path” for a component’s behaviour as well as mock “failing” scenarios such as submitting incorrect form data. There are many categories of tests implemented in Storybook, including Accessibility, VIsual, Interaction, End-to-ends, etc.

Advanced usage (Custom Controls)

Depending on the context, you may need to develop custom controls to be able to test every possible case for a given component. Such an example is the DataItem component which can be used to display a list of data fetched from an API. The component is structured to contain multiple child components, like a checkbox, avatar, text, etc. and they are displayed in a specific order. For instance, a checkbox and an avatar may not be required depending on the situation. As such, custom controls are created using React local state to update which components are checked and therefore displayed in the component.3MW9F6gW ckiDI4v5qEXip6 3CD5tRbBxwgt6wT2xE2aR41Sh4gHYYVoGlpKNHRDv0hmcWSZB5kx18MWfqVtOFsyxEjcJU yem SBC7DLx9KNXlfDR5LiLlTVLUzs6H h6mLgNeeUr4Xugw8C4pbnqU - What is Storybook: A Complete UI Components Guide 

Figure 4

image 13 - What is Storybook: A Complete UI Components Guide 

Figure 5

Final thoughts

Storybook can be an invaluable tool for the entire team. It organizes commonly used UI components in one place, serving as the source of truth. This means having less chaos, less confusion among team members, and less UI inconsistency. When used well – and, like we said, that requires relatively little effort to do – it ultimately leads to efficient delivery of new features and fixing existing UI problems.

Categories