Welcome to the Guide to Building a Company Component Library course.

Course Welcome

The different types of component libraries and their uses.

An Intro to Component Libraries and Design Systems

Syllabus

How to setup your environment to complete this course.

Environment setup

Introduction

Which React Components to Build? An Atomic Design Guide

Which UI Elements Should be Turned Into React Components?

Choose React Dependencies for a Maintainable Component Library

Shared components

How to Host an NPM Package in GitHub for Free

How to Add Storybook to React to Test Component Library Locally

How to Keep React Code Consistent With Prettier and ESLint

Library creation

Build a Custom React Button Component With forwardRef API

Build a Custom Design System With React Styled Components

Validate React Props With PropTypes and TypeScript

Shared component patterns

How to Design Compound Components With React Context

How to Design Custom React Field Components With useUniqueID

How to Extend Styled Component Styles With New Style Props

Advanced patterns

How to Test React Component Libraries With ts-jest

How to Build Tests For React Button Components

How to Build Accessibility Tests For React Field Components

Component testing

The Best Ways to Bundle React Modules Into Packages

Build process

Setting Up Continuous Integration for a React Component Library With GitHub Actions

Deployment and automation

This course will teach you how to create a flexible, private, enterprise-grade component library using React.

Since its introduction in 2013, React has become one of the [most used front-end frameworks](https://2019.stateofjs.com/front-end-frameworks/). Its component-based architecture and flexibility has made it the framework of choice for those needing to share code across multiple teams.

However, the same flexibility that has helped React grow in popularity also creates many challenges when creating shared assets and tooling. Some of the most commonly asked questions include:

- What components should be shared?
- How do I choose which dependencies to include in my library?
- Which component APIs and design patterns allow for the most flexibility?
- How do I document and build my components?
- How should I be testing my library?
- Where do I deploy my components for internal use?

This course will teach you how to create a flexible, private, enterprise-grade
component library using React.

The newline Guide to Building a Company Component Library

How to identify potential shared components in an existing codebase

Importance of choosing your libraries dependencies

How to create an NPM library from scratch with TypeScript and Storybook

Basic and advanced API patterns for shared components

How to build and deploy a modern NPM package to a private NPM registry

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. 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. 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 are a centralized collection of reusable UX patterns, style tokens, and voice and tone guidelines that are applicable to many different platforms. Whereas a component library is a collection of reusable abstractions for a specific experience. Component libraries are often confused for a complete design system.

---
title: An Intro to Component Libraries and Design Systems
description: The different types of component libraries and their uses.
role: "INTRODUCTION"
privateVideoUrl: https://fullstack.wistia.com/medias/qs5tmzfw28
isPublicLesson: true
---

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. 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. 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.

Austin Green

The most common reason for implementing a component library is the need for

By abstracting common business logic, styling, and features, you are able to

experience for the end users of your product, as well as an improved developer

With the flexibility of React and the variety of library choices in the

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

When building a new library, the trick is to make it flexible enough to support

cases and product needs you don't know about yet.

Design systems, as a concept, are a centralized collection of reusable UX

tokens, and voice and tone guidelines that are applicable to many different

Whereas a component library is a collection of reusable abstractions for a

Component libraries are often confused for a complete design system.

But not all component libraries are design systems, and not all design systems

Some of the most popular open source component libraries implement design

We have Material UI, which is an implementation of the Material Design System.

Fluent UI, which implements the Fluent Design System.

And for example, the Zendesgarden React implementations are shareable

The requirement for a design system to be flexible and unappinionated may not

use cases for your teams and the types of logic they need to share.

The techniques shown in this course are applicable to design system components,