Don’t Build a Component Library without a DesignerFionna ChanBlockedUnblockFollowFollowingApr 21Photo from Unsplash by Harpal SinghAsk anyone who has worked with me, and you would know I am an advocate of front-end component libraries.
Be it in React, Vue, Angular, or even Vanilla JavaScript, I believe the future of web lies in component libraries.
But today I am here to tell you this — sometimes you shouldn’t build a component library.
If you have read some of my articles about product development, you would think I am contradicting myself because I insisted on building the minimum viable product in a technically scalable and maintainable way, with a component library of course.
So according to me, it seems under all circumstances building a component library is a no-brainer.
I do wish this one rule fits all in real life, but alas, I must warn you of reality.
Don’t Build a Component Library in These 3 CasesOut of all three cases, here are the two cases that are not worth diving deep into:If you are building mini-sites or marketing campaigns, orIf you are building a prototype that will never become a sellable productIn these two cases, what you are building are one-off non-iterative deliverables.
You don’t need to build them in a scalable or maintainable way as long as you can produce them as soon as possible, and therefore there is no need for a component library.
The third case is the only case in which you should not build a component library even when you desperately need one: It is when you don’t have a designer.
3.
Do not build a component library for your product if you don’t have a designer.
To understand the reason for this advice, we have to first understand the role a designer plays in the birth of a component library.
A component library is a design system translated into code.
The designer would produce the design system with Sketch / Figma / Zeplin / Adobe Photoshop & Adobe Illustrator.
The design system should consist of:brand voicebrand and product colour palettes / colour schemestypography styles (font size, font weight, and font family)spacingicon setscomponent look and feelcomponent interactive behaviour, andlayout patternsThe design system has to be built after conducting extensive external and internal research.
It is a large project that requires at least one UX designer.
The designer(s) should have the ability to take ownership of the creation of the design system from research to defining the items on the above list.
The designer(s) should be comfortable with:wireframingdrawing up sketches (mock-ups)communicating with different stakeholders (e.
g.
the brand owners, and the product owners), andwriting the style guide documentationThe component library built without the basis of a design system would be subject to potential drastic changes.
The most worrying part is the behaviour of the components.
It is easy to set variables for colours, font size, font family, and spacing and change them later on.
But if the behaviour of the components need to be changed, the DOM structure might need to be reconstructed in a total different way, and the previous styling code (in web’s case it’s CSS) would need to be discarded.
Let’s take a form field component as an example.
Your DOM in the component library v0.
0.
1 could be:<label> <span>Field Label</span> <input type="text" /></label><style> label span { font-size: 16px; }</style>And then you decide you don’t want a label, but only a placeholder:<label> <input type="text" placeholder="Field Label" /></label>Or you decide that it’s a good idea to have a label, but you want it to look like Material Design so that it would cover the field when it is empty, but then stay above the input field when the input field is not empty:<label> <input type="text" /> <span>Field Label</span></label><style> label { position: relative; } label span { position: absolute; top: 20px; left: 20px; font-size: 16px; transition: top 0.
3s, font-size 0.
3s; } label input.
not-empty + span { top: 4px; font-size: 12px; }</style>Of course, this is an over-simplified example to illustrate that some sort of changes have to be made to the DOM and CSS when the component behaviour is changed.
Real cases are often way more complicated than this example because components can be written to cater multiple behaviour and one minor change in the DOM can break several use cases.
Defining the DOM and the styles once and not making major changes is the core benefit of creating a component library.
If this benefit is non-existent due to the lack of design resources, it is better that you don’t build a component library.
What You Should Do InsteadUntil you get more design resources, I recommend you to use an open-source component library, with which you can customize the colours and font family.
It should also be well-documented.
Basically, that would mean any one among the three popular CSS libraries Bootstrap, Material, and Bulma.
Click the links below to check out the component library implementations of these CSS libraries for different front-end JavaScript frameworks:For React code base: Bootstrap, Material-UI, and BloomerFor Vue code base: Bootstrap, Material, and BuefyFor Angular code base: Bootstrap, and MaterialIt seems like there is no open-source Angular Bulma component library out there yet!For Vanilla JavaScript code base: PolymerIf you do not want to use a component library, just use the original CSS libraries: Bootstrap, Materialize, and BulmaThe idea is to build your product with a component library, and then your team can make decisions on a few customizations like the theme colours and font family.
The component behaviour can also be customized to a certain point, e.
g.
the side menu should show on top, or on the right, or at the bottom, or on the left.
Try out the drawer demo on Material-UI: https://material-ui.
com/demos/drawers/#temporary-drawerUnless you have a justified need of a tailor-made component library*, it is usually a better idea to use an existing open-source component library.
*i.
e.
There are various complex foundation components that you would reuse a lot throughout product development but there are no existing component libraries for that, a good example would be the Reaction Bar and Buttons of Facebook posts:A screenshot of the Reaction Bar and Buttons on a Facebook postRemember that you can always build several extra components in your code base, and build most product features with components from an open-source component library.
It does not have to be a binary choice.
SummaryYour product will undoubtedly be slimmer if you build everything from scratch because you will only build a just-enough amount of functionalities for your components instead of importing the versatile and highly customizable component code from a component library.
However, you must consider whether you have the resources to maintain whatever tailor-made solution you create in the long run.
For small startups, more often than not, building a component library without relying on an existing open-source component library is too resource-demanding and hence not worth the investment.
Think carefully before making any technical decision as big as building an in-house component library.
Developers have to understand that even if you have the ability to build a very good component library, it does not mean you should dedicate so much time to build one from scratch.
You want your product to get as much development resources as possible, so build on top of the cornerstone (a good open-source component library), and show off your team’s software engineering skills by building great product features.
Follow me if you like this article!.I would share my thoughts on front-end programming and startups whenever I have time ????.