设计系统：组件的组合哲学

在大型组织中，产品更新迭代速度飞快，公司需要快速行动、持续开发、交付新产品并维护现有产品。为此，我们采用的解决方案是构建一个设计系统，该系统植根于通用图案、色彩、排版和网格的原则。

对于负责将设计系统具体化为组件的团队来说，最大的挑战在于如何展现公司快速的发展节奏，并持续为产品团队创造组件价值。由于产品不断发展，组织的开发人员希望能够超越实现阶段，但有些开发人员只想跟随实现阶段的步伐。

在这种环境下，设计系统团队面临着巨大的挑战。设计方面，设计系统团队可以采取不同的方法，将设计限制在特定的组件用例中，或者只创建基础部分（例如颜色、排版、间距、网格、布局……），或者同时满足这两种情况。每种情况都有其优缺点，您需要了解如何在组织环境中更好地运用每种情况。

另一方面，组件库的开发人员可以采取不同的方法：

这样做的结果对双方来说都是不好的，我们可能会让开发人员感到沮丧，因为他们可能必须创建自己的组件，或者他们必须使用灵活的组件做大量的工作才能达到由其团队的设计师创建的设计的具体情况，而设计系统可能会阻碍设计师的创造性思维，因为组件定义是固定的。

纠正和处理这个问题很复杂，但我们应该怎么做呢？在我们公司（Liferay），过去我们一直采用固定组件的设计系统方法，不允许开发人员超出预期。在一个拥有 300 多名工程师和多个产品团队的公司环境中，这是一个糟糕的决定，导致组件的采用率很低，原因如下：

结果导致我们的组件 API 庞大，使用率低，配置复杂度高，维护成本增加，并且很快进入折旧阶段。

我们知道这是一个糟糕的决定，并于第二年迅速转向了另一种方法。我们采取的方法是在组件库的灵活性和专用组件之间取得平衡。

处理这个问题似乎比较容易，但我们如何才能实现这个想法呢？我们对组件采取了一种混合方法，我们称之为多层 API 库。

多层组件意味着我们有两种方式来提供组件：

这些原则非常基本，但要想获得称号，您需要遵循一些法律。

低级组件遵循组合，例如构建 DropDown 组件的小块。

<ClayDropDown />
<ClayDropDown.Action />
<ClayDropDown.Item />
<ClayDropDown.ItemList />
<ClayDropDown.Search />

高级组件也可能遵循组合，但可能是更具体的组件，在许多团队中具有一些共同点。

<ClayButtonWithIcon />
<ClayCardWithHorizontal />
<ClayCardWithNavigation />
<ClayDropDownWithItems />

高级组件由低级组件构建，这可能会减少维护但增加可用 API 的表面。

这样做的好处是，您可以提出一种混合方法，以获得更多采用者以及具有不同品味的团队。

这种方法的结果是我们的组件在不同环境的不同团队和产品中得到广泛采用，从而帮助团队更快地交付并且更加快乐。

这似乎解决了用户层面的问题，但我们也参与了多次关于如何区分、构建和构建低级和高级组件的讨论。我已将我的一些想法与试图遵循理论或概念并随着时间的推移进行调整分开。

不要将其与长尾效应理论混淆。

尾部理论就像一根绳子，它有两个末端或尾巴，在绳子的两端分别放置两种类型的组件，低级组件和高级组件。它们之间的距离可能带来巨大的痛苦，也可能带来巨大的成功，在这里，要么全有，要么全无！

卡住的组件越多，随着时间的推移，其变化就越大，并且其生命周期也越短。

该图表是假设的，这里没有使用真实数据，而是基于我长期使用组件库的经验。

一些奇怪的事情：我们可能在短期和长期内低级工作得很好并且变化很少，这对我们来说是理想的情况，但在中间有一件事我们可能会失去，那就是努力和开发经验：这些是人们采用库组件并毫不费力地构建的关键点。

非常具体的组件可能会随着时间的推移在短时间内发生很大变化，有时我们可能需要对组件进行折旧，以解决其膨胀的问题。任何组件都可能发生这种情况，但我们会面临维护问题，并且需要不断努力更新组件才能让用户开始使用。我们可以延长这些组件的使用寿命并减少维护，这样我们就可以专注于改进或构建组件以外的产品。

想象一下，如果我把组件越来越靠近绳子中间，两侧之间的距离就会减小，这意味着我们减少了两侧的疼痛，但靠近并不会带来明显的差异，反而会造成混乱。每当我们给高层赋予一些灵活性，把它们推到绳子中间，体验就会变得更好，疼痛也会减少。

请注意，我们不想加入双方，而是想让他们靠近，尾部是极端，极端是有代价的，我们只是想让他们保持距离，我们需要为高级组件提供一些灵活性，并降低低级组件的灵活性。

考虑到这一点，我们可以：

虽然最大的好处在于高层，但低层也会受到影响，因为一旦我们拿走它的一些自然灵活性，随着时间的推移，它的变化量就会略微增加，对它的维护也会增加，但这是必要的，因为我们必须创造一种平衡，两者之间的差距并不明显。

我相信坚持这个理论会更容易。一旦我们理解了，就能自然而然地判断组件何时需要更多灵活性，或者何时需要维护 API。

我们的 Liferay 组件库是开源的，您可以通过 Github 访问它：

我已经为此工作了两年半，我很高兴听到您的想法和经验。

我们的 Github 仓库里充满了各种有趣的想法和演讲。快来探索我们的 Issue 和 PR 吧 🙂。