Skip to main content

Storybook

The application will come with Storybook already integrated. We recommend to use it actively and develop as many components as possible creating stories for them. This allows easy debugging, maintainability, and sharing the UI.

We believe that Storybook can help in your workflow and in the maintainability of your app. It helps to create UI components in isolated environments, and promotes best practices like decoupling the UI from the third party services, APIs, etc.

By following this approach, it is faster to create new UI components, to find edge cases that could produce bugs, and maintain the UI by fixing bugs directly in Storybook.

This would allow you to not have to refresh your app every time you need to fix an issue or create a UI feature. That can be really time-consuming when you need to follow several steps to reach the page, or when the client's API is down.

To run storybook, you only need to run:

npm run storybook

And to build a static files site that is very easily hosted:

npm run build:storybook

All the configuration for Storybook is under the .storybook directory. There it would specify to import the stories for a pattern like **/__stories__/*.stories.js.

The more complex the UI component is or more combination it has, the more benefits you will get by using Storybook as it will allow structuring the UI better and to quickly test different cases without the need of running the whole app.

Best Practices​

The most important points to take into consideration:

Don't use external APIs in your UI​

Follow the container / component approach, where containers would use the services

Use dynamic props/args when possible​

If you use args in stories, you can update the Component behaviour easily from the Control panel

Recomendations​

Additionally, after using Storybook in many projects, we recommend the following points:

Maintain a flat structure for the stories using categories​

This makes it easier to see the big-picture and browse between the stories

Put the stories in __stories__ directories within the component itself​

That way you can handle stories better. When you remove a component, the story is removed too. Also, it makes them easier to find. This is similar than using the Jest convention of __tests__ directories.

Ignore stories from unit tests coverage and Sonar​

Stories are a mixture of tests and documentation, they are not included in the real application. However, it is recommended to still parse the stories with ESLint and stylelint.