My first introduction to the Storybook library was during a project in which we built a progressive web application. We developed this application with a team of two front-end engineers, two back-end engineers, and 2 UI/UX engineers. With this wonderful team, we considered making a Component library to speed up the development of components we use on most of our pages and projects. So we gave Storybook a shot!
Storybook is a tool used to create and maintain UI components. It allows developers to develop, document, and visualize components in isolation from the rest of an application. Storybook also helps with testing, development workflow, and collaboration between teams.
Learn about Storybook more here ➡
Before creating our first stories, we split our design into components to decide what we would put as general and page-specific parts. Then, we used Angular to make our components and our component library for our application.
To install Storybook, we used the Storybook CLI, which spared us a lot of time as it was like a three-step process. We already had the starting files, which were necessary for the CLI.
The official documentation to install Storybook ➡
We also added some add-ons to help us document all the components we were making to help our functional testers to seek out problems before they came to the application. Finally, we made sure everything was editable and customizable for every detail.
Examples of component libraries ➡
Before creating stories, you will need a separate and reused component to take advantage of everything Storybook has to offer. Next, you will need to create some stories for your components. You can create a stories folder at the root of your project and add a *.stories.ts file for each component you want to document. You will import your component and any necessary modules in each story file. Then, create a set of stories for the component using the storiesOf() function from the @storybook/angular package.
These are some helpful add-ons we used within our stories. This helped our communication with the teams and other developers. These integrations are necessary to get the most out of your component library, and this becomes a single source of truth for every component.
When developing our first stories, I saw Storybook's considerable advantages in our project. One of them was making different list types within the same component by looking at the size of the items within the list. In addition, we had to develop a mobile-like experience so the possible lists were either a grid view or list view that you could indefinitely scroll in.
Our advanced web application was a design specifically for a portrait tv screen. Then, we just had to add some options, and there it was. We didn't have to do crazy stunts inside our chrome browser. We could just hit the shortcut on the webpage, which resized into the correct format!
After every common component was set, I felt we didn't give it as much attention as before and we focused more on fixing little bugs when changing some of the items. This was fine, but it was something we should have looked into a little bit deeper. I developed more screens and components in Storybook than in the actual application. As a result, this helped speed up the development on my end.
I find Storybook a vital tool for our team. We had a lot of components, and it was a great use case to use Storybook for. However, I wouldn't use Storybook on a smaller application. This would give no extra meaning to the application as you would put more time into creating Stories than actually finishing the application.
Even though I definitely see the benefits of Storybook, I do feel we didn’t use its fullest potential in this project. You can do a lot more than I described here. For instance, the things I wish we would have used within our Storybook were the unit testing and the End to End testing. Maybe next time!
Written by
Want to know more?
