Component Libraries

A component library is a collection of low-level generic components, the LEGO bricks that every application needs. Things like buttons, date pickers, and auto-completes.

When most developers talk about component libraries, they generally mean third-party component libraries. The most popular third-party component library is Material UI.

Honestly, I don't recommend using these sorts of tools in most cases. They can be useful in a few limited use cases (eg. prototyping, building internal tools), but I personally don't believe they're well-suited to production applications.

Why not? I wrote a blog post answering this question. If you'd like to see my unabridged thoughts about this topic, I recommend giving it a read!

• You Don't Need A UI Framework

Here's the most critical point: very few tech companies actually rely on these tools. If your goal is to get a job as a React developer, you'll need to know how to build applications without relying on these tools.

I've worked at 6 tech companies, and 0 of them have used tools like Material UI.

*

Typically, we built our own first-party component libraries. At DigitalOcean, we built Walrus. At Khan Academy, we built Wonder Blocks.

To understand why very few product-focused companies use third-party component libraries, we need to talk about design systems.

A design system is what gives a brand its unique identity. It's a collection of rules that govern how a product looks, feels, and behaves. It includes tokens for colors and typography styles, as well as in-depth designs for specific UI elements.

Design systems are built by designers using design software, like Figma or Sketch. They provide these documents to us, the developer, to implement components based on their designs.

In terms of an analogy, the design system is like a recipe book. The component library is the set of prepared ingredients required — the chopped tomatoes, the puréed carrots. And then the web application is the finished meal.

Here's the problem: third-party component libraries have their own design system baked in.

Material UI, for example, uses Google's “Material Design” system. It's a very specific aesthetic, used by official Google applications across web and Android.

Now, third-party component libraries do allow us to customize/tweak the styles, but it would be incredibly difficult and annoying to try and swap out an entire design system this way. I've spoken to several developers who have tried to do this, and all have regretted it.

Here's the bottom line: very few tech companies rely on “pre-styled” component libraries like Material UI, because they want to have complete control over the branding / aesthetic. And so, to best prepare you for real-world work as a React developer, we won't use these tools either.

When building a first-party component library like Wonder Blocks, it's common for the component library to be its own project: it has its own git repository, its own landing page, its own documentation.

This is useful when our components need to be shared across multiple projects, but honestly, it adds a ton of friction.

In this course, we'll focus on the strategy I use in my actual products, like this course platform. I keep all of my components, from all over the spectrum, in a single directory.

For fun, I took a screenshot of the first few component directories from this course platform, and labeled a few of them in terms of their spot on the spectrum:

Components with a single purple asterisk, *, are the lowest-level components. It includes generic components you'd find in any component library, like Breadcrumbs, but also some of the funkier things I use in my projects, like Boop.

Moving up the spectrum, components marked with **, are a bit higher-level, things like AccountDropdown, which renders this fella in the top-right:

Finally, I have high-level components marked with ***, things like AccountPage, which renders all of the main content on the Account page.

It may seem a bit chaotic to have everything mixed together like this, but this is my favourite way to work. There's no false binary between "component library components" and "everything else". It's a spectrum, and every component has a spot on the spectrum. All of the components I need are right here at my fingertips, and I'm free to compose and enhance them however I wish.

One final note: Some of these directories hold multiple components. For example, AccountPage has the following files:

This allows me to keep related content together. I know that the MyAccountInfo component will never be used outside the AccountPage component, and so it doesn't make sense to clutter up my /src/components directory with it.