DEV Community

Discussion on: Should one need a UI Component library in 2022?

Collapse
 
michaelmangial1 profile image
Michael Mangialardi

Is this for your company and not a side project? If so, does your company have a design system?

Assuming your answering is "yes" to both of these questions, then there are several things to unpack.

First, what is Material UI (and the like)? Material UI is a very generic design system that encapsulates behavior of common UI components with the look and feel of Google's Material Design.

Since your company has it's own look and feel in a design system, you don't want to use Material UI for the purpose of getting its look and feel via its components.

Rather, you are interested in using something like Material UI as a quicker way to have UI components with certain behaviors already implemented, saving you time from writing the components from scratch.

In other words, you want headless or unstyled UI components.

It seems that the design system community has begun to realize the use of a headless UI library, and so, we've seen things like Headless UI and MUI Base.

I believe this is a positive moment, and it would be a great idea to leverage these libraries, skinning them with your own design system's theme (preferrably with design tokens).

Second, once it has been established that unstyled libraries are useful to leverage (or styled libraries with all the styles manually removed), the next question is: how do you leverage them?

My recommendation is to create a separate library with your own design system's UI components (and assets), and then you can wrap the "base", unstyled UI components, encapusulating your own styles and default behavior as needed (as well as any normalization of the prop signature to match the lingo of your company's design system).

Third, if you exporting UI components that are wrappers around "base" ones, then you also have the liberty to cherry-pick from multiple UI libraries, taking the best of the bunch.

Hope that helps!