I worked in a few companies building a UI Library or company framework to use in multiple products with the dream of having a great UI, consistency, and the same behavior for the users.

The UI Library's idea helps the developers prevent the duplicity of components, speeds up the development, and delivers the same experience in the company ecosystem.

In this post, I will explain the part of the journey in the process, and I hope it helps you take shortcuts or skip my mistakes.

When the company takes the challenge to build a component library is not an easy task, it is more than creating a project with a bunch of components.

We need to think about the following:

• How to Share the Library between projects?

• How to deliver?

• How easy is a new joiner to collaborate with it?

• How to Share the use cases covered by the library?

• How flexible does it need to be?

• And more.

Now I will expose most of the common failure points when building a UI Library:

• Don't build a design system first.

• Don't think about delivery and distribution.

• Don't take care of component API.

• Create components linked with the business.

• Isolated UI Team

• Use the Wrong tools

Design System

The design system helps us detect the status of our UI, how many components are similar, pick the starter points for the library, and create an empty list of essential elements or features.

Sadly, I always worked in an existing app with complex components and behavior. I go through every area or module in the app and create my "Interface Inventory."

Read more about Interface Inventory.

The Interface Inventory helps us define the base and list of the most used elements, the different versions of the same UI element, and use atomic design to help easy-to-compose components in the future.

Read more about Atomic Design

Delivery and Distribution

Be careful about how to distribute and deliver your components from authors and consumers. If you components coupled and link between in a single package like:

npm install @my_amazing_library

For large business components using components with different roadmap and features, one single package is not a good deal. It forces update all component versions by the library and impacts to update and don't allow delivering a specific version.

Splitting the component and version helps us to provide a small and incremental update, the redundant dependency conflicts, performance, and stability, without force update everything if you don't need it.

components
   ├─ grid-footer       5.1.1
   ├─ grid-action-button        1.1.0
   ├─ grid-header  3.7.6

Component API and Flexibility

Building a component API with flexibility is related to the "Isolated UI Team," but We need to consider who uses our components.

One solution is to write a draft before coding, or thinking about how others use our components allows us to write a semantic API.

Understanding the context helps to create a clear and semantic component like:

<amazing-chart>
    <amazing-chart-title></amazing-chart-title>
    <amazing-chart-row></amazing-chart-row>
</amazing-chart>

In Angular, we can expose the component's state in the template using exportAs, help to share the component state quickly, and reduce the amount of injecting stuff for communication.

Read more about exportAs

Consider usability and composition in our components; allow child components with <ng-content></ng-content> and build compound components.

Read more about Compound Components.

Keep in mind, the primary goal is the flexibility to provide functional components.

UI Team

I'm a huge NBA Fan, and keep in mind: two players can win games, but with a team working together with rings. The UI Team needs to work with the whole company, don't code alone or isolated. The component library is for the company, not for the UI Team.

One team focuses only on the UI Library without sharing and getting feedback from its customers (the other developers or products using it); make a library without real company scenarios or problems.

Keep in mind the following points:

• The UI Library must be open for other developers or team representatives to publish or promote components.

• Share the knowledge of new members with guidelines to publish components.

• Build your UI Team with one representative from each product or module.

Use the Right Tools

Angular has some options for building our UI library; the Angular CLI supports multiple work projects to split the code into various packages, but it is not enough.

• How do you manage multiple projects?

• How does the UI team communicate the components?

• What about testing?

• What about keeping libraries updated?

I don't want to tell you the "golden solution", or "silver bullet", and the following tools are my recommendation:

• Angular: angular.io My lovely JavaScript framework! :)

• Nx: Great nx.dev Great tool for monorepo all code in one place with consistency and easy dependency management.

• StoryBook: Simplify sandbox for other developers and the company to play with the UI components with documentation and user cases (Stories) easy. storybook.js.org

• Cypress: cypress.io cover e2e and cypress component testing and test your components quickly.

• Jest: jestjs.io Unit test for services and business.

Recap

The creation of a UI library is a huge responsibility. Take your time before starting and the company requirements.

A UI library is an investment of time and resources for the company, but the ROY is more than the code. It makes the developer fast and easy to speed the development.

Maybe I forget something else. If you want to add something, please leave a comment.