什么是设计 Token？

我最近一直在听到很多关于设计 Token 的消息，虽然我从来没有在需要它们的项目中工作过，但我认为它们非常有趣，值得记下一些笔记。据我了解，一般思路是：设计 Token 是一种与平台无关的方式来存储变量，例如排版、颜色和间距，这样您的设计系统就可以在 iOS、Android 和普通网站等多个平台上共享。

设计 Token 正在设计系统社区中逐渐流行起来，但它们并不是一个全新的概念。2016 年，Jina Anne 和 Jon Levine 做了一次很棒的演讲，他们谈到了 Salesforce 的 Lightning Design System 如何使用设计 Token。他们描述了我们所处世界的复杂性，在这个世界中，一个构建多个 Web 应用程序和原生应用程序的组织需要在外观和感觉上保持一致，同时又不会减缓开发团队的速度。Jina 还制作了 关于设计 Token 的深入视频课程，并在该课程的预览中写道

使用设计 Token，您可以捕获低级值，然后使用它们来创建产品或应用程序的样式。您可以为 UI 开发维护一个可扩展且一致的视觉系统。

让我们举一个简单的例子：您可能有一个排版比例尺，希望它在多个平台上保持一致。与其将该比例尺的值存储在 CSS 文件中并在每个应用程序或网站中复制它们，不如将它们存储在一个 JSON 文件中，然后将其转换为所有其他平台所需的代码。类似于

{
  "global": {
    "type": "token",
    "category": "typography"
  },
  "aliases": {
    "TYPE_SIZE_SM": {
      "value": "14px"
    },
    "TYPE_SIZE_MD": {
      "value": "25px"
    },
    "TYPE_SIZE_LG": {
      "value": "44px"
    }
  },

您可以编写自己的代码来获取此 JSON 文件并将其转换为您可能需要的全部变量，例如，Sass 文件将依赖于这些 Token，并可能将它们作为变量使用，这些变量将在 Web 应用程序中的其他地方使用。Style Dictionary 是一个可以为我们完成许多繁重工作的工具，它是亚马逊的 Style Dictionary，以下是该工具在实践中的示例

我认为这太棒了。而且我可以看出它如何节省大量重复代码，并避免多个团队之间的混淆，因为它充当单一事实来源，而不是拥有多个具有相同设计要求且需要维护自己的样式表的代码库。Cristiano Rastelli 也在一段时间前写了关于 使用 Style Dictionary 管理设计 Token 的文章，并深入介绍了如何开始使用。

您的事实来源甚至不必是 JSON 文件！在今年早些时候的一篇文章中，Pavel Laptev 向我们展示了如何制作这些 Figma 中的设计 Token，并通过使用他们的 API，从设计模型中抽象出这些值并在代码库中使用它们。

Pavel 将他的 Figma 文档分成不同的页面，分别用于他的网格、间距、调色板和排版，如下所示

现在，这似乎需要付出很多努力来设置，但我认为，像 Sketch 和 Figma 这样的工具只会使将来这类事情变得更容易——它们可能希望事实来源位于其特定的设计工具中，而不是其他工具中。

最后我想提到的就是 Brent Jackson 的这篇文章，他在文章中写了一些关于设计系统 互操作性 的想法。具体来说，他认为应该有一个设计 Token 规范，这样任何 CSS-in-JS 库都可以以任何格式或样式使用该代码

设计系统 Token 旨在灵活且跨平台工作，这意味着不同的团队、不同的实现和不同的库将以不同的方式命名事物。这就是这个规范的用武之地。如果我们都例如将我们的调色板命名为 colors，并将我们使用的字体大小命名为 fontSizes，就可以实现很多互操作性。您在此基础上做些什么以及您使用什么数据格式来存储这些值，都由您决定。将 JSON 转换为 ES 模块、YAML 甚至 TOML 非常简单，如果您喜欢的话。它也只是一个数据结构，因此在其他数据结构（例如设计工具或 GraphQL API）之间转换也是可能的。此标准也不会试图解决如何命名颜色本身的极其复杂问题。

Brent 接着创建了一个 主题规范 来解决这个问题。看起来，如果我们想从一个 CSS-in-JS 库切换到另一个库，或者如果我们想切换到我们尚未想象过的其他系统，拥有一个用于编写所有变量和设置的单一标准将对我们有所帮助。

总之，我相信设计 Token 才刚刚开始成为主流，随着这些工具、工作流程和标准随着时间的推移而改进，它们的普及率将会上升——所有这些都令人兴奋不已！