In this article I will share my thoughts on what a component library is and the benefits of using a component library. I will not go in to details about creating your own library. But first let's have a look at what we mean when talking about a component. When I'm referring to a component I'm talking about an entity on a web page. The term component is also commonly used when talking about systems and development in general. But here I'm focusing on element that a user can see or interact with in some way.
As I mentioned components can also consist of other components. Larger components like these make it more cumbersome to maintain. As one component is dependent on several others, it quickly becomes more complicated. A common approach to structuring components is Atomic Design. The term Atomic Design is coined by Brad Frost, who has a lot of great content written about this. I really recommend you to read about it if you are not familiar with the concept. I've used this structure in many projects. Once you understand the concept it makes it easier to create and manage different hierarchies of components.
When talking about component libraries, you might think of a large project with many developers and designers. Where the mission is to set design standards and principles for a project or company. But, the concept of a component library and its benefits are not based on the size of the application or project. I would say that a small project has as much to gain from a component library as a larger project. A component library is a set of re-usable components. It could be a folder inside your project with common components used throughout the application. It could be a distributed package on npm. It could also be a part of a bigger design system. A component library can be small and it can be large. There are no official rules for what a component library means. It depends on your project and your needs. It can be either components that you created your self or a public library from a big company. There are dozens of public component libraries that you could use and take inspiration from. I list a handful of them in the end.
If you are using a similar component in two or more different places, I recommend you to create a general component and place it inside a library folder. Then use that component in both places instead. If they need to differ in some way you can set this up with properties or other logic to determine its output.
The most classic example is a regular button. If you have a button on many places in your application it is good practice to use the same component for that button. You get a consistent look and feel to your application and you only have to make updates in one place. This is commonly referred to as the single source of truth.
Another reason to use a component library is if you are not interested in design and just want a component that looks good and does what it should. Then you can use one of the public libraries where you get a design and a battle tested component out of the box.
One huge benefit of using a component library is that you have a single source of truth for your components. There are no variations implemented in different places. All the html, styling and logic can be found in one place. This makes it easier to share. You can very quickly get up and running with a new project and have access to the components straight away. Changes to a component will be reflected on all of your projects.
When having a single source of truth for the components it's a lot easier to talk to designers and have a common understanding of how things look and feel. You can for example add Storybook to have a common place to display your components. Where you can sit together with designers and stakeholders to discuss changes and new features. It makes it easier to work with design in a more iterative way. It is possible to deliver new versions at a faster pace and easier to try out new things.
By having all your components in one place it makes it easier to maintain. Updating components or adding new features is done once and will be reflected on every implementation of that component. Pushing updates is a lot faster and more consistent. It's also easier for new employees to get a overview of the architecture and what bricks you have to play with.
It is easier to create a well thought out test suite for the components in the library when they are grouped and implemented in one place. The tests become more relevant and important to have. When adding new features it's also easy to use Test Driven Development by created the new tests before implementing the feature. I find it easier to work with Test Driven Development when having this kind of setup. Rather than having the components spread out in the application. It makes your projects more robust.
It's easy to create a small set of components. But when starting to work with multiple browsers, accessibility, design for different devices it can start to feel overwhelming. Luckily there are dozens of public component libraries for all frameworks out there. Some follow certain design principles like Material Design. Others are created by individual developers with their own preferences.
I would recommend you to check out and get to know some of the more common design frameworks for components on the web. Most of them have component library implementations for each web framework. This is a good introduction to working with components and component libraries.