Figma自动转换为代码的令牌：我们如何启动我们的设计系统 #
第一部分：进入兔子洞 #
本文是我们讨论使用Figma的API提取设计令牌的一系列文章中的第一篇。在我们深入讨论令牌提取和生成版本化库的技术方面之前，让我们先讨论为什么我们构建了这个工具以及为什么您可能也需要它。
在2019年底，我们在iAdvize遇到了一个十字路口。设计团队从Sketch转向Figma以便更容易进行协作。作为工程团队，我们已经建立了一个设计系统，用于管理样式和组件的一致性。然而，随着迁移到Figma，我们面临着一个新的挑战：如何将从Figma中提取的设计令牌自动转换为可用于代码开发的样式和组件。这就是我们构建这个工具的原因。 我们决定建立一个设计部门的React组件库，以JavaScript为基础，但随后我们将所有的应用程序迁移到TypeScript。
设计团队的示例和TypeScript当然是我们改变事物的动力之一，但我们的组件库还有其他问题，无论是技术上还是概念上。一些问题是由于缺乏维护而产生的。有些组件简直是坏的。我们在iAdvize有许多团队，他们在不同的应用程序上工作，每个团队都有自己的问题。然而，我们都使用组件库来构建应用程序，却没有任何形式的合作或指导。组件有时是由一个团队按照一个单一目的构建的，但在另一个团队的介入后变成了其他的东西。由于缺乏明确定义的范围，组件通常处理更多的用例。每一个需求都堆叠在另一个需求上，使事情变得混乱。
在这一点上，团队开始完全放弃使用该库，只是为了摆脱这种复杂性。
我们想要重新掌控。我们决定建立一个设计部门。 基于原子化方法 (opens new window)的系统。我们希望更有主见，用更少的东西做更多的事情。正如Runar Bjarnason在Scala演讲 (opens new window)中所解释的：“限制解放，自由约束”。我们希望有非常受限制的和有类型的组件，以便进行组合。我们还希望拥有构建更复杂元素的基本元素。我们从Harry Roberts的ITCSS (opens new window)中借鉴了构建系统的想法，通过覆盖范围、明确性和特定性来塑造我们的系统。在这个蓝图的基础上，我们设计系统的第一个元素必须是Tokens。它们是最小的部分，但影响最大。由于所有东西都是基于它们构建的，改变一个Token将导致应用中的所有内容都发生变化。Token只是一个变量，一个键值对，但它在设计系统可用的任何地方都可以使用。如果您想了解更多关于Tokens的信息，[这里是 使用设计团队的请求来开始移动。他们想要在所有的应用程序中更改一个颜色值。他们已经在他们那边完成了这个工作，因为Figma提供了一种在文件之间共享“样式”的方法。这样可以非常容易地在每个组件中跨越更改一个值。
我们希望在开发者方面也有相同的机制。我们想要一个单一的真理来源来替代我们四处散布的众多变量。我们甚至希望这个真理来源能够以自动化的方式来自设计师。我们觉得这是他们所有权的核心。为了做到这一点，我们决定使用Figma API并从其文件中检索这些令牌。这就是我们将要在第二部分 (opens new window)中重点关注的内容。