设计系统的创建方式有多种 — 自下而上、自上而下、外部、源自设计或开发需求以及可能的其他一些。有一点是肯定的 —— 从小事做起，同时关注未来的发展，这对于可持续增长至关重要。
您今天构建的基础必须支持当前需求，同时保持敏捷性和深思熟虑，以满足项目或组织内需求的逐步演变。本文重点关注技术支柱，这对于创建能够满足不断扩大的雄心的设计系统至关重要。
那个？ 设计系统入门模板 (DSS) 基于核心组件构建，为可扩展和可维护的设计系统奠定了坚实的技术基础。这些组件确保设计和开发一致、灵活且高效。
⭐️ https://github.com/XOP/design-system-starter
在以下部分中，我们将概述 DSS 模板的主要和次要模块及其服务和工具。此外，我们还将探索它们在设计系统早期阶段的成本效益以及在更成熟阶段的潜力。
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 - 可主题化且易于访问的调色板生成。最新版本：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)",
}
}
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.
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.
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.
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.
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
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.
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 模板并提供整体和功能性的开发人员体验。实际上，还有更多内容，欢迎探索全面的文档。
这些技术基本上可以分为“精选”、“推荐”和“自以为是”类别，因此接下来的每一项都比上一个。
考虑示例：
在所有其他技术选择中，我想（另外）突出显示固执己见的：
最后，Typescript 是在同时在所有三个组中 中脱颖而出的技术。它已经存在了一段时间并成为行业标准，通常建议用于像设计系统这样的复杂项目，出于类似的原因我也会进一步使用它。
打造任何产品都需要坚实的基础、清晰的路线图、精心的准备以及在每个里程碑时及时修改。随着需求随着时间的推移而变化，您的技术应该具有足够的弹性，能够有效地适应新的设置。
对于设计系统，它是所有，加上永动机的元素。您能想到一种通用的开发方法，可以处理项目的不可预测性和多功能性，超越良好的标记和风格吗？也许以后会这样，但现在，这就是事情的样子。
那个？ 设计系统入门模板可以帮助您建立强大的技术核心，甚至可能成为一个很好的起点，为您的下一个设计提供模块化和灵活的解决方案系统挑战。然而，在大多数情况下，它是见解的基础和灵感的火花。这种情况在我身上在 DSS 开发过程中发生过好几次，以至于以工具为中心，这就是为什么我认为它很有用。我绝对期待并邀请您参加下一次的邂逅。
以上是设计系统入门模板 - 您需要的所有技术的详细内容。更多信息请关注PHP中文网其他相关文章！
