Files
freeCodeCamp/docs/how-to-work-on-the-component-library.md
T
Oliver Eyton-WilliamsandShaun Hamilton d7848ae01a feat: migrate to pnpm for better workspace DX (#49293)
* feat: npm -> pnpm 

This resolves the issues with the gatsby client (gatsby-plugin-pnpm
deals with the fact that gatsby is relying on its own dependencies
being de-duped)
and challenge-editor (which doesn't seem to want to automatically install
codemirror and needed its own eslint config)

* fix: correct mocha path for curriculum tests

* fix: use select workspace with -F not -w

* fix: reorganise packages and restrict hoisting

pnpm works best if the workspaces keep their own dependencies, since
dependencies are not flattened and then what node resolves from a
require is predictable.

@types seem to be a special case and more care is required to prevent
them getting smushed together in the root (hence the .npmrc)

* fix: add types for tools + root

* fix: decouple challenge-auditor from client

* fix: add ui-components types

* fix(client): use the latest types for react 16

* fix: prettify

* fix: prettierignore pnpm-lock

* fix: relax hoisting

Turns out pnpm works just fine with types. I don't know what was going
wrong before, but there are no-longer any type conflicts.

* fix: add @redux-saga/core to fix eslint issue

It seems to only be redux-saga that import/named can't cope with, so it
is probably okay to work around this one.

* chore: add chai to tools/scripts/build

* fix: add store to root for cypress

* fix: allow cypress to download binaries

If we want to keep preventing cypress from downloading binaries, we can
figure out a workaround, but I'm allowing it to ease the transition to
pnpm.

My guess about why this is happening is that npm triggers Cypress's
postinstall script, but pnpm does not (because pnpm install only
installs if necessary, perferring to link)

* chore: re-enable pre/post scripts

* fix: update build scripts for client

Co-authored-by: Shaun Hamilton <shauhami020@gmail.com>

* chore: update engines to use pnpm


* fix: enable choice of (super)block for tests

Only 'nix machines for now.

* chore: pin pnpm to version 7

* chore: remove last npms

Except web + curriculum-server. I'll update them when I start work on
them again.

* fix: lockfile check to catch any package-locks

* fix(action): install pnpm for upcoming tests

* chore: add nodemon to new api

Co-authored-by: Shaun Hamilton <shauhami020@gmail.com>
2023-03-02 18:17:44 +00:00

6.3 KiB

Welcome to freeCodeCamp's ui-components library. The components are built mostly from scratch with basic HTML elements and Tailwind CSS.

How to Work on the Component Library

Note

freeCodeCamp has been using Bootstrap components in the UI. However, we are moving away from it and building our own component library, which helps standardize our UX/UI patterns and improve accessibility. The project is tracked in this GitHub issue.

The following steps are recommended when working on a new component:

  • Research and planning
  • Implement the component
  • Display the use cases on Storybook
  • Write unit tests

Researching and planning

Before building a component, you need to research and document on how the existing version behaves and looks, to ensure that the new one has matching styles and supports all the current usages. In order to meet the web accessibility requirements, you should also pay attention to the accessibility aspect of the component, see which HTML elements and ARIA attributes are used under the hood.

Once you have gathered enough information about the component, you can start thinking about the props interface. Ideally, the interface should be as similar to the current version as possible, to ease the adoption later on. Since we are using Bootstrap components, the simplest approach is to mimic their implementation.

We prefer smaller pull requests rather than a large one, because they speed up the review time and reduce cognitive overload for the reviewers. For that reason, you should think about how you would break down the implementation and come up with a delivery plan.

We recommend opening a separate GitHub issue for each component and include all the notes in the issue description. It can be used as a place to host all of your working notes, as well as a way to communicate the approach with the reviewers. We will use the issue thread for further discussion if needed. The issue for Button component can be used as a reference.

Implementing the component

A new component can be created using the following command from the root directory:

cd tools/ui-components

pnpm run gen-component MyComponent

The command will generate a new folder inside the ui-components directory, with the following files:

File name Purpose
index.ts It is used for exporting the component and its types.
my-component.stories.tsx It is used for demoing the component on Storybook.
my-component.test.tsx It is a test file.
my-component.tsx It is where we implement the component.
types.ts It is where we locate the component's interface and types.

Each component is different, but in general a component should:

  • Support forwarding ref
  • Be styled for both light and dark themes
  • Be styled internally based on their props (the consumers should not need to restyle the component with the className prop)
  • Utilize the built-in styling system from Tailwind instead of having custom styles

Using colors

There are two color "layers" in the component library:

  • The base layer, where the color names describe what the colors are, e.g. gray00, blue50
  • The semantic layer, where the color names describe what the colors are for, e.g. foreground-primary, background-danger

Generally when using colors in a component, you should choose semantic variables over the base ones. There are exceptions, however, specifically when you are styling the component's states such as hover, active, disabled, etc. In these cases, we recommend using the base variables directly instead of creating new semantic variables, since each component can have different styles for their states.

Note

Color definition can be found in the colors.css file. A color is only available for use if it is added to the tailwind.config.js file under the colors property.

Displaying the use cases on Storybook

Use cases of the component should be added to the Storybook file (.stories.tsx).

To start Storybook, run the following command from the root directory:

pnpm run storybook

The Storybook page is available on http://localhost:6006.

Writing unit tests

We use React Testing Library to write unit tests. The tests should assert that the components behave as expected and are accessible.

To run tests against the component library, run the following command from the root directory:

pnpm run test-ui-components

Adding packages to the UI-Component library

We restrict adding new packages to the UI Components to help with the project's maintainability. In the rare chance that you think a dependency is needed, please check with the maintainers first and then use the following command to add a package:

cd tools/ui-components 
pnpm add package_name