Do You Need a React Component Library?

Building a beautiful frontend is a lengthy process. Writing all by hand is possible, but it adds complexity and is not worth it in many cases. This is why components libraries exist, and they allow developers to focus on building the UI without creating everything.

React encourages developers to build components to have reusable code. Dividing a complex page into several components is beneficial for developers since it provides easier readability and maintainability. The granularity at which developers divide their screens will depend on the complexity of the components. It can be tempting to make everything a component and have complete control over the UI.

What Is a Component Library

Before discussing the advantages of component libraries, it is essential to define these libraries. As said before, it’s common to divide a screen into multiple components. Without a component library, developers might have to develop custom components for basic HTML elements such as buttons or input.

Using a component library will provide a set of pre-built components assembled. Those libraries provide the backbone required to build a UI and some basic styling to make things attractive without putting too much effort into the design.

They are the equivalent of CSS framework but built for the React ecosystems and around components. Don’t get me wrong, CSS frameworks still have a role to play in the modern web, but they are out of the scope of this article.

Is building everything a good idea?

Having complete control over every element of the UI can be a seductive idea, and you only implement the things you need to keep the number of dependencies and the bundle size low. Those valid arguments come, however, at a cost: maintainability.

With time, the components that were once simple could have additional requirements and become a spaghetti mess. For example, handling the default, disabled, outlined, loaded variants of a button will become a pain, and new developers working on the project will have trouble maintaining the code.

There are cases where it makes sense to build everything by hand, but in most cases, using a component library makes more sense. The team will lose some control over the different UI components but will be able to focus on the features of the product they are implementing.

Some Reasons to Use a Component Library

As presented before, doing everything by hand comes with maintenance costs. This cost increase is one reason for using a component library, and other aspects can motivate the usage of such a tool.

Speed

Since components are pre-built, the development time of screens will be reduced. Besides components libraries often provide some layout features such as a responsive grid or input validation.

Developers can focus on piecing the elements together and implementing the logic right away.

Customization

Having a friendly-looking default theme is excellent, but the web would be boring if everybody used the same design language. For that reason, component libraries support theming. The approach differs from one library to the other, but they all have a way to change how things look.

Some solutions let developers override default variables, and others have complex theming support where every aspect of components can be changed. Whatever the method, it’s possible to customize the appearance of the essential components of the library.

Support and Accessibility

The web is browsed by people using a broad range of devices and with different needs. Ensuring correct styling on multiple browsers and making sure that visitors with accessibility needs find the needed information is a lot of work.

Components libraries will take care of some of these elements. The responsibility of supporting older browsers will be delegated to the component library. Most of them are doing a pretty good job at it.

Caveats of Components Libraries

There are, however, things to consider before jumping on the first component library you find online. Sure, components libraries are tremendous, but there are some elements to consider before deciding to go this route.

First, not all component libraries are equals, each has its philosophy, and it’s essential to understand how the creators want you to use the library. Some of them encourage theming with powerful config a little to know predefined styles, and others like you to stick as closely to their design so you can focus on implementing features instead of spending time theming. One approach is no better than the other, but you have to understand that before choosing.

Developers can’t be proficient at their job if they switch frameworks for every project. The same applies to component libraries. They are a core component of a project, and it takes some time to understand how everything works and how to use it properly. Of course, the learning curve is lower than learning React but is still present. Choosing one component library and sticking with it is recommended since it requires some time to switch from one to another. This also applies to new developers. It will take some time to understand how those libraries work if they have never used them before.

Not all libraries are suited for all types of projects. Some libraries are good all-rounders, others focus on dashboard creation, and others help developers build static pages. It’s possible that depending on the use case, the team should change the library and use something more appropriate to the project. Choosing a component library is not something written in stone. Of course, having a default choice is recommended, but flexibility is required (even mandatory) depending on the type of project the team is implementing.

I want to discuss one last point: customization can be tricky with some libraries. I already talked about this point, but I want to reiterate since it’s an issue we faced at my current position. We used for quite some time a popular component library called Ant design. It’s an excellent solution, but we had a complex design project and had trouble implementing it using Ant. We had to override many Ant classes, resulting in a hard-to-maintain code. This point ties with my previous one: not all libraries are suited for every use case.

How to Choose a Component Library

There are several elements to consider before choosing a component library. Many options are available on the market, and it is essential to start by making an inventory of what’s expected from the library before starting the research. For example, it’s great to see in previous projects which components were difficult to implement or which part of the code required a lot of work.

This inventory allows you to define the criteria that the library must fulfill. The projects carried out may be very data-oriented with graphics and charts or, on the contrary, a relatively simple library is needed covering the basic components and offering good customization.

Once the requirements are established, it’s possible to consider the following points.

First, the number of components offered and if they correspond to the team’s needs. Some libraries decide not to implement many components and leave the responsibility of creating the more complex one to the users. This makes sense in some contexts but can be a problem for a small team that wants to delegate as much as possible to focus on the application’s logic.

Having a library with the correct number of components is a good thing, but it is also essential to analyze the exposed properties. These properties allow configuring the way the component is displayed and interacts. A button, for example, often has several variants (primary, secondary, outlined) and several states (disabled, loading). Not having enough properties can force the development team to create components that act as middlemen that require maintenance, which can cause problems and defeat the library’s purpose.

Another important criterion is the support of forms and their validation. Making an efficient form with good validation and error support is not easy. Some libraries integrate their way of doing things, so it’s up to the team to adapt, while others support standard market solutions like Formik or React Hooks Forms. The second case can be more appreciated because these libraries are known, and team members will find help and resources online.

Customization is also important. One of the critical values of component libraries is the personalization of the application’s look without writing hundreds of CSS lines. Each library is very different in that regard, and if the developed applications have a very customized design, it is essential to pay attention to this point. Some libraries will offer simplistic customization, which can be overwritten, while others have extensive confirmation of each component and its state.

I won’t go into too much detail about other less critical points, which may be necessary in some cases, such as the size added to the bundle or RTL support. Teams having those concerns can quickly narrow their search by focusing on those elements reducing the number of available solutions.

I recommend taking the choice of a component library seriously and testing the options to make sure you make the right choice. It is interesting to reproduce the same screen using different component libraries to get an idea of the strength and limitations of each option. Doing this exercise helps determine the quality of the documentation, the components implementation, the layout support (especially for responsive questions), or the properties. At the end of this test, it is possible to make a motivated choice that will suit the team.

So, Do you need a component library?

We discussed component libraries, why they exist, what they bring to the table and what to look for when trying to find one for your next project. But do we need a component library? Well, that depends.

If you want a short answer, yes, you need one and won’t take too much risk going for any of the most popular ones.

Are you not convinced? Let’s discuss why you might want to add a component library. Firstly, there are some speed benefits, and having a set of ready-to-made components will support the implementation of more complex templates or screens. Instead of managing props of a custom button, you’ll focus on the logic of your application connecting data.

Delegating the responsibility of complex tasks is something we all do. Authentication services such as Auth0 or Firebase Auth make logins and sessions easier to implement. Hosting our websites on crazy fast servers that scale with Vercel makes our lives easier. Why not taking doing the same for components? We can all agree that building a custom set of components takes time. Why not reduce this time a bit and leave that job for someone else?

Choosing a component library doesn’t mean starting the project over. Let’s say you have a project, but it’s getting hairy to maintain it. Switching to a component library to reduce some of the complexity doesn’t mean that you have to change everything at once. Adding a component library to a project means that new features use the library, and the team can migrate older code along the way.

Finally, using a component library can be good for the team. Web applications are a complex beast. Creating a robust, tested, responsive, and immediate product is the fruit of hours of work. Instead of controlling everything, reduce the pressure and let other people help you. Our developer’s time is valuable, and let’s focus on the value of our product instead of satisfying some of our desire to control everything.

As you might understand, I’m pretty favorable to components libraries. This might come from my experience in an agency dealing with tight budgets. There are cases where creating something from the ground up makes sense. It’s out of the scope of this article, but I will take this in a following article. Feel free to subscribe to the newsletter to receive a shiny email for each piece I publish (I won’t send any other email). You can also comment below to share your thought on the subject!