Maintaining Multiple UI Projects
Hello everyone, in this article we will discuss the advantages and uses of integrating Storybook into our front-end development team’s workflow. The incentive to find a library that could easily store and display isolated components came about naturally as the team had to cope with implementing and maintaining multiple customized, but similar interfaces for a commute logging system (Person A checks in at 7:35 AM, checks out at 6:11 PM).
There are many distinguishing characteristics in the table component alone between the two pictures shown above. Not only are they different in data format and style, but also heavily coupled with their respective project due to the compilation of several data sources. This way of implementing can cause all sorts of dependency and rendering issues that could show up in production.
Juggling between multiple codebases
The first and foremost issue with maintaining several projects is the sheer number/size of codebases to familiarize with. Should there be a bug to fix or feature to add, a developer needs to have at least basic familiarity with how a certain page is rendered, its components, and how the data gets populated/mutated to meet each technical need.
However, differences in imported libraries and tightly coupled components make it needlessly more difficult to debug and improve. More often than not, an issue would be raised because a component did not render correctly in a certain width, the input data was formatted incorrectly, or a timing issue caused the wrong state to be displayed.
Reaping the benefits
When we first came across Storybook, it looked promising as a viable solution to our problems. Having to categorize isolated components incentivizes current and future developers to implement on a component-based development model so that they would program outside of the immediate project scope and be less inclined to create tightly-coupled code.
Storybook addons provide a templated way of documenting properties, events, and slots such that the outcome is both visually pleasing and easy to read. The customizable controls allow for both developers and designers to be able to visually observe modifiable variables in a sandboxed testing environment.
The key advantages to the development team are as follows:
- Reduced development time: Building modular components takes advantage of the inherent reusability to allow pages to be created faster and makes composite components easier to design.
- Lower learning curve: Learning the in’s and out’s of discrete pieces of an interface makes it much simpler to gain familiarity of the overall application structure.
- Easier maintenance: Testing components in isolation allows developers to find and debug issues better and earlier than before. Storybook also has a plethora of addons designed specifically to help with the testing process.
- Better upgrade process: Components and associated functionalities can be upgraded incrementally to ensure stable updates across all the projects that they are featured in.
While the current implementation of Storybook for our team is still young and few in component count, there is much potential for its growth. There are still many components to refactor from the existing codebases and many ways to use Storybook addons to better inform, develop, and test. Once our team is able to fully flesh out the component library for all of our projects, it will become remarkably easier to transition frontend knowledge to any user- developer or not.
Thank you for reading! 👋