Let’s distill down the essence of what makes a component library. A component library is a set of reusable components that are cohesive in their utility, or appearance (or both). A great component library will help developers achieve their UI needs efficiently, while offering an exemplary experience for the end user.
Who doesn’t like music? Everyone loves a good album! Imagine if albums didn’t exist as we know them. Instead of recording music to tape, CDs, or as digital files, the only way we could listen to an album was by requesting the band to play an album for us in its entirety.
Any time anyone wants to listen to the album, they’ll need to go to the band, ask the band to set up their equipment and play the album, front to back. While this would result in a fun live experience, it’s not an efficient way to ensure that everyone interested in the band’s music can listen to it.
The band would need to repeat the same work over and over again. To ensure that every listener has the exact same experience, they’d carefully play it exactly the same every time. The band gets fed up performing the same work over and over again.
So how does this relate to writing components? Imagine that every time you wanted to write a UI pattern, like a card, or a dropdown, you had to write the entire thing from scratch, and you couldn’t reuse the code. It’s inefficient, repetitive, and increases the likelihood of inconsistencies appearing over time. We write our code as components so that we can reuse the code whenever we need to in our project. This is similar to a band recording a song once and then playing the recording at will.
Finishing the recording is just one part of the job. Even with the recording completed, the band still needs to put it in a format that’s easy for people to consume, and then distribute it for anyone to access. The band could choose to publish their music on CDs only. While a great deal of music fans have the resources to listen to CDs, it massively reduces the total number of people able to appreciate the record. The band could instead choose to publish CDs, cassette tapes, and on streaming sites, that way almost everyone can enjoy the music.
Back in front-end development-land, you’ve written your components and used them in your own projects. You begin to see how they could serve your other projects and the web development community at large. This is where the real challenge comes in, you have to:
It’s not easy doing this for the first time, and a lot can go wrong.
There are other things to consider too, like if you wrote your component library using a particular framework, as this can lock the consumers of your component library into using that particular framework. In this course, we’ll look at ways to write your components to ensure they work regardless of which framework the consumer is using.
We’ll be looking at solving these problems and more in this course!
Before jumping into the meat of the course, let’s refresh ourselves on what exactly a component library is.
Writing components is an inevitable part of front-end development.
You may have written UI patterns like buttons, cards, and menus as components, where you define the implementation once, to reuse across your entire application. Here’s how a humble button component might look written using React syntax:
// Button.jsx
const Button = ({ label, variant = 'primary' }) => {
return (
<button type="button" class={`button ${variant}`}>
{label}
</button>
);
};
// Checkout.jsx
const Checkout = () => {
return (
<div>
<h1>Checkout page</h1>
<Button onClick={addToBasket} variant="secondary" label="Add to basket" />
<Button onClick={completeCheckout} label="Complete checkout" />
<Button onClick={emptyBasket} variant="secondary" label="Empty basket" />
</div>
);
};
Now if you wanted to use that same button in several projects, you’d need to copy and paste the Button
component into each project. In this case, it’d make sense to pull out the Button
into its own library, so that you can reuse it across your projects.
You’re also not limited to consuming components that you’ve authored. There’s a wealth of third-party libraries that you can use across your projects.
So if we go back to the initial description of a component library:
A component library is a set of reusable components that are cohesive in their utility, or appearance (or both). A great component library will help developers achieve their UI needs efficiently, while offering an exemplary experience for the end user.
Being efficient is one of the greatest skills a developer can have, and building components once and reusing them will make you a more efficient developer. You’re spending less time reinventing the wheel and more time getting the job done, be it your professional day job, or your personal passion project.
Humans are fallible and error prone and aren’t motivated by repetitive work.
We’re computer programmers because we enjoy technical challenges, and writing the same components over and over again is not a fun challenge. Over time it gets boring, and as we get bored we becoming inattentive. Being inattentive can lead to mistakes in code, which can lead to your web experiences becoming unusable. Take the following example of a dialog
component’s implementation.
This example:
It takes work to remember and implement the above, but the consequence of getting it wrong can be catastrophic for your web experiences. For instance, incorrectly using the dialog element, or implementing the same behaviour from scratch can render your interfaces unusable.
Because component libraries make you more efficient, you’re saving your company money. This compounds the more front-end projects your company builds. For every new front-end that your company manages, more time and money is saved be reusing the components.
As a result, you’ll build interfaces more quickly and your components will be battle tested, having spent time in different contexts. More robust web interfaces means fewer broken experiences, which leads to happier users. If a user is happy using your product, they’re much more likely to continue using your product.
For a company that manages several different public facing web applications, it’s highly likely that they’ll follow a set of guidelines. By writing the same component in multiple places, you increase the likelihood of your application deviating away from the style guide. By having a component library, you can more easily audit your components UI against the brand guidelines to ensure that they look great, wherever they’re used.
Uber has several different apps that share the same user interface elements. I’m almost certain that they use the same component library across these apps. That way each new app is virtually guaranteed to adhere to the brand’s guidelines.
I hope that by now, even if you were a little skeptical about component libraries to begin with, that I’ve fully convinced you about the plethora of benefits that building and consuming a component library brings.