設計系統入門範本 - 您需要的所有技術

設計系統的創建方式有多種 — 自下而上、自上而下、外部、源自設計或開發需求以及可能的其他一些。有一點是肯定的 —— 從小事做起，同時關注未來的發展，這對於永續成長至關重要。

您今天建構的基礎必須支援當前需求，同時保持敏捷性和深思熟慮，以滿足專案或組織內需求的逐步演變。本文重點在於技術支柱，這對於創建能夠滿足不斷擴大的雄心的設計系統至關重要。

那個？ 設計系統入門模板 (DSS) 基於核心組件構建，為可擴展和可維護的設計系統奠定了堅實的技術基礎。這些組件確保設計和開發一致、靈活且高效。

⭐️ https://github.com/XOP/design-system-starter

在以下部分中，我們將概述 DSS 模板的主要和次要模組及其服務和工具。此外，我們還將探索它們在設計系統早期階段的成本效益以及在更成熟階段的潛力。

核心組件

UI 函式庫：設計系統的核心

DSS UI 函式庫作為 DSS Template 的核心支柱，使用 React-aria 構建，以確保可訪問性優先的無頭 UI 元件。雖然 React 是選定的模板框架，但 DSS 旨在輕鬆適應其他框架，如 Vue 或 Solid。這種適應性使團隊能夠選擇最適合其專案需求的技術，而無需被鎖定在特定的堆疊中

對於樣式 DSS UI 依賴 vanilla-extract，它提供了強大的可擴展的零運行時 CSS 基礎。再一次，它是一個靈活的選擇，允許使用 CSS 模組、Panda CSS、Tailwind 等替代方法。

為了穩定性，UI 元件依賴測試庫，首先專注於功能。特定的測試場景可能與主題（無頭）組件無關，但在其他場景中至關重要。

產生的組件結構看起來相當簡單：

Switch/
  index.ts
  Switch.css.ts       - styles created with vanilla-extract
  Switch.spec.tsx     - tests using testing-library
  Switch.stories.tsx  - documentation with Storybook stories
  Switch.tsx          - component based on react-aria

值得一提的是，即使 DSS UI 沒有遵循多包方法，它仍然允許進行樹搖動，利用 Vite 配置中各自的匯總選項：

// named import
import { Button } from '@ds-starter/ui';

// default import
import Button from '@ds-starter/ui/components/Button/Button';

UI 函式庫的一個關鍵面向是早期納入設計令牌。令牌是在整個設計系統中保持一致樣式的基礎，甚至允許不使用完整 UI 庫的項目從有凝聚力的設計語言中受益。有了適當的語義標記，就可以輕鬆更改顏色，而無需進行大規模重構。此外，透過模組化方法，我們並不真正關心如何建構設計令牌，而是輸出什麼。

設計令牌：一致性的支柱

設計代幣是設計系統的一致性和靈活性不可或缺的一部分。它們提供了跨所有模組和應用程式的主題和樣式標準化方法，確保 UI 的每個元素保持凝聚力。

DSS 顏色標記 使用 ? 生成Unicornix 是一款允許創建可訪問且可自訂的調色板的工具，可以輕鬆啟動淺色和深色模式。版式和其他一些標記是用 ? 建立的設計令牌產生器。總而言之，這為進一步擴展而不會遇到重大障礙提供了堅實的基礎。

unicornix-npm

Unicornix - 可主題化且易於存取的調色板生成。最新版本：0.7.0-beta.0，最後發布：9 天前。透過運行“npm i unicornix”開始在專案中使用 unicornix。 npm 註冊表中還有 1 個使用 unicornix 的項目。

npmjs.com

DSS Tokens are available in both CSS and JavaScript formats, to reflect and support different project needs, from simple websites to complex web applications. Theming can be done in several ways, and here we fully rely on CSS custom properties.

Here is an excerpt from the generated CSS.

It’s easy to note that theme can be swapped completely by changing a single data attribute:

:root[data-theme="light"], [data-theme="light"] {
  --awsm-color-content-strong: rgb(24, 26, 27);
  --awsm-color-content-regular: rgb(45, 47, 49);
  --awsm-color-background-regular: rgb(255, 255, 255);
  --awsm-color-background-subtle: rgb(236, 237, 237);
}

:root[data-theme="dark"], [data-theme="dark"] {
  --awsm-color-content-strong: rgb(255, 255, 255);
  --awsm-color-content-regular: rgb(229, 230, 231);
  --awsm-color-background-regular: rgb(0, 0, 0);
  --awsm-color-background-subtle: rgb(9, 10, 11);
}

JS tokens can be consumed as CSS refs, containing the references to values, rather than the color strings. This approach is great for semantic variables and theming without sacrificing performance:

export const tokens = {
  content: {
    strong: "var(--awsm-color-content-strong)",
    regular: "var(--awsm-color-content-regular)",
  },
  background: {
    regular: "var(--awsm-color-background-regular)",
    subtle: "var(--awsm-color-background-subtle)",
  }
}

Icons and Fonts: Modular Visual Language

The Icons and Fonts modules add depth to the visual language. Icons are managed through an efficient process that generates components from SVG files using SVGR and tsup. This ensures that icons are consistent and can be flexibly integrated across the system.

Similar to UI components, icons can be also imported individually:

// named import
import { IconX } from '@ds-starter/icons';

// default import
import IconX from '@ds-starter/icons/lib/IconX';

// Source (SVG) import
import IconXSrc from '@ds-starter/icons/svg/x.svg';

The Fonts package offers a convenient solution for managing typography within the Design System. It supports both base64-encoded fonts for quick setups and Google Fonts integration for more robust implementations, giving teams the flexibility to choose the best approach for their project’s needs while maintaining consistent typography across all digital products.

It’s worth noting that while base64 encoding is efficient, it’s not effective for production setup. Yet in the early stages it can be a common denominator for consistent typography. Of course going further this should be replaced with the more appropriate fonts-loading strategy.

---

Now, the question arises — should you setup Icons and Fonts packages from the start? The answer naturally depends, however in most typical scenarios it will be a “no”. More agile environment in the early stages is crucial and less dependencies is the key. Yet, keeping in mind the upcoming structure and incorporating that in the early setup is a good idea, shaving off a couple of dozen “story points” in the future refactorings.

Documentation — Storybook and Beyond

Storybook: A Multi-Purpose Development Tool

Storybook is an important tool for UI development, serving primarily as a development environment and a documentation portal on early stages of Design System. It allows to visualize and interact with UI components in various states and configurations, resolving issues early in the development process.

Storybook in DSS is a standalone app that does not itself host any stories — they all are collected across the packages and composed in one central hub. This way DSS Storybook can document color palettes, typography, iconography etc. along with the UI components from different sources after a simple setup.

? Note that there is no storybook composition per se, 

yet it’s also possible as one does not deny the other.

Explore the deployed demo here: https://ds-starter-storybook.vercel.app/

Beyond its direct functionality, DSS Storybook is additionally equipped with Visual Regression Testing (VRT) and Accessibility Testing using Playwright. Such automation is essential for large design systems, where manual testing could quickly grow ineffective and time-consuming. By integrating these tests into the development workflow (early), DSS ensures that the Design System can evolve fast without fear of regressions.

While being an irreplaceable tool for early-stage documentation, consolidating component documentation and visual examples into a single platform, Storybook is not actually a documentation website. With time, more sophisticated, content-oriented and customizable solution is demanded, especially for the Design System consumers far apart from technology.

Documentation Website: Design System Knowledgebase

As the Design System matures, the need for more detailed and accessible documentation becomes paramount. The DSS Documentation Website (DSS Docs) addresses this need by providing a dedicated application for organizing and presenting information about the Design System.

Explore the deployed demo here: https://ds-starter-docs.vercel.app/

DSS Docs is designed to be minimalistic yet highly functional and customizable. It includes several modules that can be tweaked and modified to meet the project purpose. Powered by Astro and enhanced with nanostores state manager, DSS Docs implies two main types of content: Articles and Component Documentation.

Articles offer in-depth insights into Design System concepts, provide guidelines, patterns and describe foundational layers in detail. To add a new Article is as easy as simply to place a Markdown file into the respective folder.

Component Documentation includes interactive examples dynamically loaded from the Storybook stories. This integration solves a couple of issues — it ensures consistency across the “Dev” and “Prod” documentation and avoids redundancy in content creation. 

? As a bonus — component examples can be edited in the UI library and will be automatically picked up by Docs running in dev mode. Not a Storybook replacement, but can be useful for cosmetic updates.

New Component Documentation can be added with a MDX file, following a particular schema. Apart from the main description, extra sections can be added following the “Usage” pages example.

Expandable structure of DSS Docs allows for easy updates and tweaks, making it an essential tool for teams looking to step up from Storybook without significant effort and creating redundancy. The Documentation app is themed with DSS Tokens to ensure a consistent look and feel of the main product.

Automation and Workflow Best Practices

Scripts and Github Actions Automation

DSS leverages a series of scripts to handle essential tasks like testing, linting, formatting, and dependency management. Turborepo offers great help for running scripts effectively, especially when every module adheres to a unified standard.

What’s more, everything that we run locally, including Visual Regression Testing — can be done on CI, thanks to Github Actions. Apart from the thorough quality checks, Github Actions will take care of apps deployment too (powered by Vercel). Naturally, all scripts are configurable and optional.

Changelog and Release Management

DSS uses Changesets to automate the processes of changelog generation and packages releases, ensuring every change is tracked and properly versioned. Needless to say, both processes are supported by Github Actions as well.

Here are some examples of published NPM packages:

• @ds-starter/fonts

• @ds-starter/icons

• @ds-starter/tokens

• @ds-starter/ui

Component Generator

To further enhance productivity, DSS includes a Turbo-powered Generator that simplifies the process of scaffolding new UI components. Apart from saving time, this allows to greatly reduce the human-error-copy-paste factor.

# Run a generator
$ pnpm run gen:ui

After replying to a series of prompts, you will get the following:

• New component scaffolded in the DSS UI package, containing all respective files

• Same component added to the DSS Docs application, with the correct MDX frontmatter data

Like almost everything in DSS, generator template can and most probably need to be tweaked to the project needs. This is a completely arbitrary operation, however using generator can be very beneficial for contributors, onboarding of team members and scenarios like codebase migration.

Flexible Technology Stack

Main Design Principle

Design System technological stack is an arbitrary matter, however it’s for sure not random. It’s a natural effect of multiple contributing factors, including, but not limited to:

• product scope and project peculiarities

• initial size and future ambitions

• teams expertise and proficiency

• contributors and consumers proficiency

• client requirements and technical stack

• overall codebase age and historical reasons

• existing technical debt

• cross-platform and cross-browser support

• maintainability requirements

• existing or upcoming deadlines

• industry trends and market volatility

• organization structural changes

• 還有更多…

？您對這方面的專門文章有興趣嗎？請告訴我！

⭐️還有，你已經突破2000字了，閱讀冠軍！

DSS 範本的目的不是遵守每一個場景，而是建議業界平均最佳實踐，可以根據所需的體驗進一步客製化。可以理解的是，模板不適合許多系統，但可以探索、重複使用、改進所呈現的模式和片段，並有望激發新的創作。

精選、推薦、自以為是

在整篇文章中，我們觀察到使用了多種技術來建立 DSS 模板並提供整體和功能性的開發人員體驗。實際上，還有更多內容，歡迎探索全面的文件。

這些技術基本上可以分為「精選」、「推薦」和「自以為是」類別，因此接下來的每一項都比上一個。

考慮範例：

• React 被選擇作為最受歡迎的 UI 庫解決方案，它非常適合演示 UI 庫腳手架。
• React-Aria 推薦，因為它是優先考慮可訪問性的無頭 UI 解決方案；我們不需要發明具有典型功能模式的輪子，也不需要解決很多可訪問性問題。
• 使用 Biome 進行 linting 和格式化是一個固執己見的選擇（我欣賞交鑰匙配置和出色的性能），並且可以用 ESLint 和即 Prettier 替換。

在所有其他技術選擇中，我想（另外）突出顯示固執己見的：

• Vanilla-extract 作為 CSS 解決方案非常適合優先考慮效能和伺服器端渲染相容性的可擴展專案。雖然它的入門門檻較高，但它提供了非常友善的 CSS-in-JS 體驗沒有 CSS-in-JS 的缺點。
• 當涉及到應用程式中簡約且有效的全域狀態管理時，Nanostores 是首選解決方案。它在島嶼式建築和 Astro 項目中尤其閃耀。 DSS Docs 具有用於基本操作（例如切換主題或原始程式碼）的 Nanostore，但它能夠管理更複雜的任務。

最後，Typescript 是在同時在所有三個組中 中脫穎而出的技術。它已經存在了一段時間並成為行業標準，通常建議用於像設計系統這樣的複雜項目，出於類似的原因我也會進一步使用它。

---

結束語

打造任何產品都需要堅實的基礎、清晰的路線圖、精心的準備以及在每個里程碑時及時修改。隨著需求隨著時間的推移而變化，您的技術應該具有足夠的彈性，能夠有效地適應新的設定。

對於設計系統，它是所有，加上永動機的元素。您能想到一種通用的開發方法，可以處理專案的不可預測性和多功能性，超越良好的標記和風格嗎？也許以後會這樣，但現在，這就是事情的樣子。

那個？ 設計系統入門模板可以幫助您建立強大的技術核心，甚至可能成為一個很好的起點，為您的下一個設計提供模組化和靈活的解決方案系統挑戰。然而，在大多數情況下，它是見解的基礎和靈感的火花。這種情況在我身上在 DSS 開發過程中發生過好幾次，以至於以工具為中心，這就是為什麼我認為它很有用。我絕對期待並邀請您參加下一次的邂逅。

以上是設計系統入門範本 - 您需要的所有技術的詳細內容。更多資訊請關注PHP中文網其他相關文章！