![[Intro.] Build a token system for UI component lib](https://cdn.sanity.io/images/xmky2006/production/7b8ee0c5f93c0e661e1f0004b3fc20d0dbeee162-1756x986.png)
[Intro.] Build a token system for UI component libJanuary 19# Tech# Front-End# Token System
What are we building?
As front-end developers (referred to as FE below), we usually choose a UI component library to quickly build a beautiful page. There are now many open-source component libraries available for us to choose from, some of which are very simple, while others have very cool animations.
Typically, a UI component library comes with a well-thought-out design, offering an out-of-the-box style that's already quite appealing, catering to the needs of most developers. However, in some cases, you may have a theme customization requirement:
- For individual developers
- A desire for a personal website to switch between multiple themes.
- Aspiration for different styles for the official websites of various products.
- ...
- For enterprise developers
- Different product lines within the company require UI components with unique styles.
- Upgrading the product image necessitates a change in the UI style of the website.
- ...
In these cases, we need UI components to quickly adapt to different UI styles, including theme color, border-radius, padding, margin, etc. When using a traditional component library, we have to write some code to override the original style of the component, and this process is repetitive and tedious.
Furthermore, manually tweaking style code brings another problem: how to ensure that the UI style display of the component aligns with the designer's (referred to as UED below) design draft. Usually, before FE embarks on development, it is necessary to align the design details with UED. During development, the objective is to translate the component style in the design draft into style code and ultimately present it to the user. Before the website goes live, UED usually needs to manually check whether the visual effect of the webpage is consistent with the design draft during the testing and acceptance phase.
Under this workflow, for FE, coding involves considering a myriad of style details, such as the border-radius of a Button or color transparency, etc.; at the same time, for UED, especially for teams that pay attention to enterprise images and are very strict about design details, in the acceptance phase, they may even need to use an inspector on the webpage to rigorously check the design elements in each component during the acceptance phase. This process is labor-intensive and burdensome for both FE and UED.
So, is there a way to alleviate the woes of both FE and UED? That is to say, allow FE to shift focus from the style details of the component to logic writing while enabling UED to save on acceptance costs and concentrate on the design draft itself.
I've envisioned a workflow: when UED designs the style, the backend can record the component design details in a certain data structure (that is Token) and synchronize them to the remote end; the remote end can automatically compile the code based on the data structure output by UED, restoring the design details one-to-one. This not only ensures the perfect restoration of the component design details but also improves efficiency. Changes to styles can be more agile, eliminating the need for FE to write additional code.
Here is the demo video:
How does this work?
The workflow is designed as follows:
It is mainly divided into two stages:
- Development stage
- Release stage
The main technology stack includes:
- Component Token system: This involves building a component that integrates the token system for theme configuration capability.
- Figma token plugin: Manage token system in Figma and export tokens.
- Style Dictionary: Tool for token compiling.
- Storybook: A frontend workshop for building UI components and pages in isolation
- [Brief]Test: This involves building a component system with integrated tests, including component tests, snapshots, and other testing functions.
- Vitest: Fast testing framework.
- CI/CD: This is for automation for testing and publishing.
- Github Action: GitHub workflow.
I will write several articles with a demo to introduce the details of this workflow as well as automated testing and deployment.
In the end
The main goal of this workflow is to solve the problem of how FE and UED can cooperate quickly in a fast-iterative background, swiftly build multiple sets of theme UI components, and implement automated testing and deployment to boost delivery efficiency. According to the workflow I introduced, combined with some open-source headless component libraries (such as Tailwind Headless UI, and Radix UI), a configurable theme and highly agile UI component library can be quickly and easily built. Furthermore, a user interface can even be built to quickly output a set of custom-styled components by online modifying some parameters with timely feedback.
