Why you should build your own component library

In today’s front-end world, you have a large selection of Javascript libraries / frameworks to choose from, but whether you are writing enterprise applications, maintaining multiple applications with some degree of commonality, or planning for a long shelf life for your application, you should consider using your own components library.

Photo by Artem Kniaz on Unsplash

“Why do I need it”, you ask?

Because it will remove a lot of clutter from your application, it will promote reuse of components (inside the application or between applications) and it will enable stakeholders (designers, product, management, co-workers) to be part of the process (e.g. by showcasing this library).

Maintaining a separate components library even promotes better design decisions (e.g. decoupling, SoC) since it doesn’t allow you to make use of your application resources (style, state, language, etc.)

So why not use a solid well known library?

You can of course, and most component libraries are doing a very good job, but if you’re working for an organization, then you should consider the following pain points:

1. Control — you will probably get to a point where you need a more fine grained control over the components.
2. License — There are thousands of license variations out there, and not all types are suitable for usage in commercial products. You probably knew that already, but did you know that a commercial company needs to consider and verify all of the licenses for all of the dependency tree?
3. Agility — you might think that you’re speeding things up by using a 3rd party library, but you will eventually realize that you spend much time in trying to hack it to do what you want
4. Size — larger applications usually suffer from performance penalties, so it’s best to have a component that does exactly what you want — no more, no less
5. Security — Whether you’re using a well known or an unknown library you might get security vulnerabilities. In well known libraries, that might be because they are targeted more

This is not to say that you should re-invent the wheel, but most generic components are very easy to write. In some situations, however, it is okay to consider using a 3rd party, but be sure that you wrap it in your component (this way, you’ll be able to replace the library if needed) and you still need consider the pain point above.

The bulletins above are valid for all 3rd party libraries (e.g. you probably don’t need a library to deep clone an object or to get a DOM element)

Don’t let the fox guard the hen house

So, you’ve decided that you want a component library, and the question now is “who is going to be in charge of that library”?

Ideally, it should be someone neutral and not someone who’s in charge of another application in the organization, simply because there is more risk that the design will be biased towards a single use case without considering the larger picture.

You should also consider that maintaining a component library is an on-going task. You need someone who will have a proactive approach toward improvements, refactoring and even rewriting the code whenever needed.

If you don’t have anyone neutral, pick one that is less likely to exploit his position and make sure that he or she is following the guidelines for maintaining a component library.

One guideline to rule them all

Even if you are not going to release this library as an open source project, consider it as such

In a nutshell, it means:

• generic, generic, generic — if your components have a specific logic, they should probably be in a separate place (*)
• footprint — should be low with as few dependencies as you can
• independent versioning
• “coupling” between components should be kept to a minimum
• purity — components should rely solely on their props

(*) you should consider maintaining another library that will be less strict (doesn’t have to be generic or keep purity of components) for handling all of the non-generic components / utilities.

Conclusion

Separating your generic components from the rest of the code will improve your design decisions, especially if you follow the open source library mindset, and can have a big impact on your organization.

If your organization doesn’t already maintain a library, you should definitely bring it to the table, and if you do, make sure that you do it right. In the long run, the organization and the developers will greatly benefit from it.