If you’ve been building components for Sitecore for a while or you’re new to the environment being able to quickly visualize your components can, at times, seem to take a while. If you’re a front-end developer, you may have known about or even used a product called Storybook. It’s a tool for building, mocking, testing and documenting UI components and pages they are on.
Let’s examine the top benefits of utilizing Storybook as part of your development process.
By removing the clutter of working amongst other components, developers can focus solely on a single component through isolation. As someone with ADHD, improving focus vastly improves the speed at which I can see results and reduces the number of potential bugs in the future.
System design and security both benefit from component isolation since it helps to prevent failures, flaws, or vulnerabilities in one component from having an impact on other system components. Also, it makes it simpler to maintain, upgrade, or replace particular components without impacting the entire system.
When a problem arises, pinpointing its origin and identifying the component to blame is simpler. This is because it is simpler to identify the root cause of the problem and test potential remedies. After all, each component is independent and has its own set of inputs and outputs.
This allows for a faster turn-around of finding the bug, identifying the cause, fixing, and redeploying the solution.
Using Storybook, you’re more likely to build components that are not “one off’s.” It strives to push developers to improve reusability, maintainability, scalability and consistency. Focusing on reusability, when you build components that are more building blocks, e.g. a card that is part of a card carousel, or a button that is part of the card carousel, it greatly reduces the need to rewrite code, reducing the number of potential bugs you will encounter. Wouldn’t you like to fix a single bug and have it fixed across the site rather than fixing it three, four or more times?
This also improves standards and aligns with a website or applications design standards.
Every developer knows that consistency is key to clean and sustainable code and ensuring that components work seamlessly together and can be tested consistently. Not to mention, consistency will enable the transition to a support team and a client with greater understanding and likely a more positive delivery.
There’s also the fact that if there is more than one developer on a project (which, when it comes to Sitecore, is a high likelihood because you can separate aspects like back-end and front-end development), using Storybook ensures the similarity to how components are built from developer to developer. When you need to swap out resources, train someone, or assist each other on issues, you’re shrinking that potential knowledge gap and time to resolve said issues or training.
One could say that cross-project integration is an entire benefit unto itself. The ability to reuse components within a single project and build them so that you can take one component built for one particular project and, through a different set of configurations and conditions, repurpose it for another project makes an incredible amount of sense.
Building up your component library that you can show to your clients, and demonstrate how it can be configured easily to accommodate their branding and theming, allows you to go from concept to dev much faster.
Having components set up through Storybook conditions enables QA team members to view components in various states and configurations to ensure they look and behave as expected according to designs. A QA can determine these conditions ahead of time or as part of the design mocks.
Creating snapshots of the component in the different states and configurations allows you to compare how the design changes over time. This helps with improving functional regression testing. Following this documentation, you can set up Storybook Snapshots, aka Storyshots, (which are powered by software called Jest).
Using an addon such as
storybook-addon-actions, you can log and inspect interaction events within Storybook. That way, if you want to do some debugging for things like button clicks or even form submissions, you have that power.
With this addon, you can enable this “annotation” in a really simple manner.
Say we’re building a card component, and we want to log when that button is clicked, perhaps because that card component might also be part of a carousel and we’re tracking on the data used. The other beauty here is you don’t have to fill your component with
console.log entries. You can read more on the action options are found here.
One of the best aspects of the ability to test is quickly validating whether your component meets accessibility standards such as WCAG and ARIA. You can even go one step further and use
storybook-addon-a11y to check automatically for any existing accessibility issues and provide a potential solution.
You can read more about how to go about setting up and configuring the A11y addon here.
As mentioned above, you can integrate testing frameworks like Jest and the React Testing Library to enable both unit and integration testing when validating how a component works with other components.
For visual regression testing, other solutions like Cypress, aka cypress-storybook and Chromatic, can be integrated with Storybook for additional options.
Clearly explaining, whether to a client, an author, or another developer, how to use a particular component, including its required parameters and whatever other relevant information, enables them to quickly consume that invaluable. When a client understands a component, they’re much more likely to use that component across their site. The more complex, the less likely unless it’s been thoroughly explained to them.
Presenting the potential multitude of variations a component might have and its flexibility for customization up-front allows both clients and QA teams to see without much effort any potential changes that might be necessary or how amazing a component is.
Storybook allows you to create pages and even directories for components and their variations isolated from other components. If one component has different ways of behaving depending upon the data provided to it, you can simulate that version without needing your QA team to go through the process of either “finding it” or setting up the system for it to occur.
Using Storybook, you can demonstrate the difference between a poorly written component and a component that meets the best practices that your team strives for. When more people follow the practice of using Storybook as part of their development process, the greater chance you have of having all components meet the standard.
Documenting and keeping track of dependencies within a component and a project might not seem important initially. Still, it’s invaluable to have an accurate list when looking at maintenance updates and full-level upgrades.
Sharing code snippets from a component build as part of the documentation process allows other developers to implement features in other projects quickly. This could be styling dropdown menus or even more complicated carousels.
How often have you searched StackOverflow or Google for code examples? Clean, clear code examples show other developers how to use a function, class, or component and demonstrate the proper syntax and usage patterns to help them avoid common mistakes and or errors.
I’m also someone that learns by seeing a real-world example. When you can see how it’s used, you can grasp the concepts faster and apply them to your project with greater understanding.
There is also the fact that this improves communication and builds trust not only amongst your fellow team members but between you and the client as well as those in the industry.
Not only documenting the accessibility requirements but also potential recommendations for a component to ensure it meets the standards, however light or heavy might be necessary.
Being able to capture the theme and styling of a component as well as how a user interacts and or changes the theme, is something that may be of great use to authors.
Within Storybook, some features enable components and configurations as if they were a live site. Adding relevant content and images improves the quality of the component for testing and also for client review.
While it's hard to accurately state an exact percentage, as each website and component are different, studies and industry experiences have shown that component reuse can lead to cost savings of anywhere between 20% to 50% or even more in some cases.
As stated earlier, the fewer components you have to build, the more individual aspects of an application you can reuse, and the larger the reduction in maintenance. Having a button component used in 10 components is better than finding a bug with a button in 10 different components and having to address each individually.
A well-documented component library in Storybook can considerably speed up the onboarding process for new developers entering the team. They can become effective team members more quickly by becoming familiar with the already-existing elements, design principles, and functionality.
By integrating Storybook with several testing tools, complete and automated testing for components can be achieved, leading to fewer errors and higher-quality finished output. As a result, it will be less expensive to rectify problems or correct defects once the websites have been published.
Let alone the fact that if you’re reusing more components, if one an error occurs in a component that is reused, you can fix it once and then be able to quickly see all the places it’s used.
It doesn’t happen often, but sometimes clients will ask for a proof of concept. What better way to use Storybook than to reuse existing components from other projects, customize them with appropriate content, theming and quickly turn around something to the client?
Utilizing Storybook, connecting in external design sources such as Figma, enables a centralized location to track the design progress, feedback, bugs and improvements in a single place. As a result, you’re now reducing the guesswork of where to go when looking for changes or if requirements have been met.
Every meeting matters when you’re under the gun to get a component or site out the door for a client. That’s because, certainly, for developers, it means they’re likely not building and creating the components. Having Storybook up and running during a meeting means you can quickly scan what’s new, what’s been updated, and any comments and then get back to work.
Discussions that could take 30 min or more might now be doable in 15min or less. All thanks to having a single point of focus to discuss relevant tasks of the day.
Head on over to Storybook and follow the directions to install it and the components you need.
Sign up to our bi-weekly newsletter for a bite-sized curation of valuable insight from the Sitecore community.