Things I learned while building my Component Library

Component libraries have changed how we build applications. It gives us the essential building blocks to develop an application's UI while hiding all the complicated logic from us to achieve that behavior. And the funny part is, the majority of the developers don't understand what is happening behind the scenes. This is a good thing, as it tells us that the library that you are using is quite good, and flexible to achieve your goals. So overall component libraries are great, they are flexible, customizable, and correctly documented and most of them work out of the box.

But if you are a front-end developer, you must understand and know what is happening behind the scenes. This can make a ton of difference when you are building a component on your own without any help from a component library. Because at the end of the day, the component library can be framework-specific, while this knowledge is transferable.

Let's take an example, to help you understand why you should know about this. Have you ever visited a website,

• Where the link is just on the text instead of the whole button
• Keyboard navigation doesn't work, inside a menu or something similar
• Tabbing and focus are not working properly, for example, in case of an alert dialog, the default focus should be on the less destructive button, like a cancel button.
• and many more...

You can easily find these types of problems on old, or even on some new websites.

In 2024, building a website is not just about putting some divs and adding the content. It's about accessibility, user-friendliness, theming, and consistency across the whole application.

A component library takes into account all of these problems and on top of it, provides a thoughtful and easy-to-use API.

Tho these problems might seem like minor issues that can be easily solved, and yes they can be. But it's about the thought process when you are building stuff. Many of us don't think about these issues, but once you start to, things change. You start to notice these things in your interfaces, and other's interfaces and you will find gaps. And this is what marks the difference between a senior and a junior developer or a good and a bad app.

And you will also tend to realize that using native components is far better than making custom ones, like a date picker. Because all the aspects of this component are managed by the browser, or the OS and if you make yours then you will need to handle this on your own. You can use a library, but if it has a bug then you are stuck until it is resolved.

Let's now dive a bit deeper, and let me tell you about the libraries that I used to build my component library.

1. Radix Primitives

You might have heard about it and maybe also used it. These are like the barebone components for React which you can use directly also to build applications. It includes most of the commonly used components like Dialog, Slider, Menu, Popover, etc.

And you might be thinking, If I am already using this why am I even building one in the first place?

So basically, these are primitives, and as the name suggests these are just barebone components that handle the working logic and API. There are no styling and theme options available.

You can make your components from scratch, all you need to do is achieve all the accessibility features and make these components as per the WAI-ARIA design patterns, it should be consistent between all browsers too, and keep it up to date with the web standards.

I don't know about you but I am happy to pass all this work on to a library. 😂

It is not impossible to make all these components from scratch, and you will have to make custom components. Because the radix components set is small, it will manage to help you with most of the interfaces. But for some advanced and more complex ones like resizable windows and command palettes, you might need to find another library or make it yourself.

2. Tailwind

Now for styling, we are going to use TailwindCSS. I think I don't need to tell you why this is the best choice. You can already find plenty of articles, regarding why TailwindCSS is so great and better than runtime CSS.

3. NX

Building and managing multiple and heavy apps can be quite cumbersome. You will require a tool to manage your mono repo so that you can store your docs, storybook, and library code in a single folder. And NX is great for this sort of work. it's blazingly fast in building your app and caching it, which makes consecutive builds fast.

I can not emphasize this more if you are building a large project like building a component library, you should use a tool like nx to manage it. It will make your life so much easier.

You can also use turbo repo, which is another project which tries to achieve the same thing. It's just that NX worked for me and also it was in the market way before Turbo.

4. Rollup

This is so much better than webpacks. It's simple, easy to use and the important this is, it's easy to understand. Because webpacks are verbose, you have to tell it all the things, and a lot of configuration goes into it. When you are building a library these configs can slow you down.

Rollup provides a simple API that is easy to understand. And it does most of the heavy lifting for you. If you are building something complex and want control over it, then you should go for webpacks, but still, 90% of the scenarios rollup should be enough.

You can also use Vite, at the time of building the component library, the support for library mode was not stable. I did ask the team about this at the time, and they told me they were not sure if they were going to work on it. I am also a Vite fanboy like most of the other developers, thanks to its outstanding performance. I do use it for my storybook setup, but for building the library, I use rollup.

5. Storybook

You need to test all your components. You can create a react app to test them or use the tool that the industry uses, Storybook. You can easily create an isolated environment to test your components and test them. It comes with a ton of features to help you with your work.

It can do a lot of testing for you. If you can automate the testing of the components, you can check Cypress or PlayWright. They can even provide you with screenshots of when the error occurred.

6. Docs

Documentation is important! You should most definitely write about your components on how to use them. You just need a simple website or even just use MD files to write about them.

It doesn't need to be perfect but just enough so that others can understand. Add property tables, examples, and other things so that people can start using them.

Conclusion

I learned a lot. From building better components to libraries and publishing them on npm. It took me 6 months to complete all of this. And yes I know this sounds like a lot of time, but I had my fun. Building this gave me insight into what goes into building a library which others can also use and cherish.

The thing I love most about JS is that there are a ton of tools to choose from. These tools which I have listed here are the ones, which worked for me and my team. And there are plenty of more options out there which work for you. So don't be shy and do tell us about some of the alternatives that worked for you.

If you want to check out my component lib, here are the links -

@rafty/ui

GitHub - github.com/rhinobase/raftyui
Docs - rafty.rhinobase.io

Do let me know what you think about it and how we can boost the community in the future. Do show us your support by giving us a star and for more content like this in the future.