An Intro to Component Libraries and Design Systems

The different types of component libraries and their uses.

Project Source Code

Get the project source code below, and follow along with the lesson material.

Download Project Source Code

To set up the project on your local machine, please follow the directions provided in the README.md file. If you run into any issues with running the project source code, then feel free to reach out to the author in the course's Discord channel.

Lesson Transcript

  • [00:00 - 00:15] The most common reason for implementing a component library is the need for consistency. By abstracting common business logic, styling, and features, you are able to provide a consistent experience for the end users of your product, as well as an improved developer experience for those building it.

  • [00:16 - 00:30] With the flexibility of React and the variety of library choices in the ecosystem, there isn't a hard rule of what should be abstracted into a component library. In this course, we will be focusing on techniques and API patterns that allow for the widest range of uses.

  • [00:31 - 00:48] When building a new library, the trick is to make it flexible enough to support the use cases and product needs you don't know about yet. Design systems, as a concept, are a centralized collection of reusable UX patterns, style tokens, and voice and tone guidelines that are applicable to many different platforms.

  • [00:49 - 00:58] Whereas a component library is a collection of reusable abstractions for a specific experience. Component libraries are often confused for a complete design system.

  • [00:59 - 01:10] But not all component libraries are design systems, and not all design systems have component libraries. Some of the most popular open source component libraries implement design systems.

  • [01:11 - 01:20] We have Material UI, which is an implementation of the Material Design System. Fluent UI, which implements the Fluent Design System.

  • [01:21 - 01:35] And for example, the Zendesgarden React implementations are shareable components that implement the Zendesgarden design system. The requirement for a design system to be flexible and unappinionated may not meet the use cases for your teams and the types of logic they need to share.

  • [01:36 - 01:41] The techniques shown in this course are applicable to design system components, but this isn't the main focus of the course.

  • [00:00 - 00:15] The most common reason for implementing a component library is the need for consistency. By abstracting common business logic, styling, and features, you are able to provide a consistent experience for the end users of your product, as well as an improved developer experience for those building it.

    [00:16 - 00:30] With the flexibility of React and the variety of library choices in the ecosystem, there isn't a hard rule of what should be abstracted into a component library. In this course, we will be focusing on techniques and API patterns that allow for the widest range of uses.

    [00:31 - 00:48] When building a new library, the trick is to make it flexible enough to support the use cases and product needs you don't know about yet. Design systems, as a concept, are a centralized collection of reusable UX patterns, style tokens, and voice and tone guidelines that are applicable to many different platforms.

    [00:49 - 00:58] Whereas a component library is a collection of reusable abstractions for a specific experience. Component libraries are often confused for a complete design system.

    [00:59 - 01:10] But not all component libraries are design systems, and not all design systems have component libraries. Some of the most popular open source component libraries implement design systems.

    [01:11 - 01:20] We have Material UI, which is an implementation of the Material Design System. Fluent UI, which implements the Fluent Design System.

    [01:21 - 01:35] And for example, the Zendesgarden React implementations are shareable components that implement the Zendesgarden design system. The requirement for a design system to be flexible and unappinionated may not meet the use cases for your teams and the types of logic they need to share.

    [01:36 - 01:41] The techniques shown in this course are applicable to design system components, but this isn't the main focus of the course.