Pattern Lab和有效的样式指南的品质

在上一章中，我介绍了用于构建用户界面的原子设计方法。希望你会发现原子设计对于构建UI设计系统是有用的思维模型，但是现在是时候从象牙塔上爬下来，然后将原子设计实际应用于现实世界了。

基于模式的设计和开发的基础是模式库（UI库？），它是构成用户界面的所有UI组件的集中枢纽。正如我们在第1章（参见原子设计1——设计系统）中讨论的那样，模式库的好处很多：

• 他们可促进整个体验的一致性和凝聚力。
• 他们加快了团队的工作流程，节省了时间和金钱。
• 他们在项目涉及的所有部分之间建立了更加协作的工作流程。
• 他们建立了团队中每个人（包括第三方开发者）之间的共同语言。
• 他们提供有用的文档，以帮助教育利益相关者，同事，甚至第三方。
• 它们使跨浏览器/设备，性能和可访问性测试更加容易。
• 它们为团队提供了对未来友好的基础，可以随着时间的推移进行修改，扩展和改进。

听起来不错，对吧？我几乎可以听到你说：“我一生中需要整个模式库。” 但是我们如何获取模式库呢？好吧，您来对地方了，朋友，因为本书的其余部分正是针对这一点。本章将介绍用于创建模式库的有用工具，下一章将讨论如何使模式成为设计和开发工作流的基石，第五章将介绍如何使设计系统经受住时间的考验。

本章将通过称为Pattern Lab的工具来讨论有效模式库的质量，该工具是由Web开发人员Dave Olsen，Brian Muenzenmeyer和我维护的一个开源项目，用于执行原子设计系统。尽管我将兴奋地讨论Pattern Lab及其各种功能，但我想强调的是，本章的重点是介绍结构良好的模式库的特征，而不是向您出售任何一种特定工具。Pattern Lab甚至不出售！没有哪种工具可以完美地适合每种设置和方案，但是在决定使用哪些工具来创建模式库时，请牢记以下原则。

Pattern Lab到底是什么

它是

• 用于构建原子设计系统的静态站点生成器工具。
• 模式文档和注释工具。
• 模式入门套件。

它不是

• UI框架，如Bootstrap或Foundation。
• 取决于语言，库或样式。
• 内容管理系统的替代品。

让我们从术语“静态站点生成器”开始逐步讲解。静态站点生成器工具会获取一些源代码和资产，对其进行编译，然后在另一端吐出普通的HTML，CSS和JavaScript。Pattern Lab接收源代码（即模式），并将这些模式编译到模式库shell内的功能性前端UI中。

一个默认的Pattern Lab仪表板。它缺乏漂亮的外观，却在实用性方面得到了弥补。

为了避免像Bootstrap这样的UI框架进行错误分类，故意删除了设计，因此没有人会错误地将Pattern Lab的演示UI用作建议的样式。对于如何设计或构建前端代码，Pattern Lab没有提供任何答案-你必须自己做所有工作。你选择用来创建UI的外观，命名约定，语法，结构，库和脚本完全取决于你和你的团队。哎呀，您甚至可以在Pattern Lab中使用UI框架，例如Bootstrap 。Pattern Lab就是在那里，可以帮助将所有东西缝合在一起。

除了技术方面，Pattern Lab使用PHP或Node.js作为将模式缝合在一起并生成模式库的引擎。但是，你无需成为PHP或Node专家即可使用Pattern Lab，就像无需知道如何构建内燃机就可以驾驶汽车。此外，你的最终网站不必使用PHP或Node构建即可使用该工具，因为Pattern Lab的输出是与后端无关的HTML，CSS和JavaScript。因此，像任何技术决策一样，选择适合你组织基础架构的模式库工具，并与团队合作紧密结合。

使用Pattern Lab构建原子设计系统

要了解Pattern Lab背后的核心概念，你需要了解俄罗斯嵌套娃娃。

原来这个时候就流行俄罗斯套娃了吗（滑稽）

俄罗斯套娃（又称俄罗斯嵌套娃娃）是精美雕刻的，尺寸不断增大的空心木制娃娃，彼此放置在一起。Pattern Lab中的模式以类似的方式操作：最小的模式（原子）包含在较大的模式（分子）中，更大的模式（组织）中包含这些分子，而更大的模式（模板）中则包含这些组织。

以这种方式构造UI会使事物保持干燥（DRY），这是一个长期的计算机科学原理，代表“不要重复自己”。这意味着你可以对模式进行更改，使用该模式的任何地方都将随着这些更改而神奇地更新。这种俄罗斯嵌套娃娃方法极大地加快了你的工作流程。

（译注：原文讲了许多Pattern Lab的实现，这里我简单概括一下，毕竟Pattern Lab想实现的东西（组件化）在现代前端框架中已经可以依靠自身实现了）

<!-- Pattern Lab实现一个header组件（双括号里面用的是Mustache，一种无逻辑的模板语言） -->
<header role="banner">
    <!-- logo 原子组件 -->
    {{> atoms-logo }}
    <!-- 导航 分子组件 -->
    {{> molecules-primary-nav }}
    <!-- 搜索栏 分子组件 -->
    {{> molecules-search }}
</header>

// 最后整个header封装成一个组织组件
{{> organisms-header }}

（译注：有必要强调一下，这里虽然说是套娃，但页面并不是由原子-分子-组织-模板一级一级嵌套上去的，上一章作者也说过，原子设计并不代表整个页面是线性的，看一下最后由Pattern Lab形成的主页模板就知道了）

{{> organisms-header }}
<main role="main">
    {{# hero }}
    {{> molecules-hero }}
    {{/ hero }}
    <section>
        {{# experience-block }}
        {{> molecules-block-main }}
        {{/ experience-block }}
        {{# experience-feature }}
        {{> organisms-story-feature }}
        {{/ experience-feature }}
    </section>
    <section>
        {{# factoid-advertising }}
        {{> organisms-factoid }}
        {{/ factoid-advertising }}
    </section>
    <section>
        {{# advertising }}
        {{> molecules-block-main }}
        {{/ advertising }}
    </section>
    …   
</main>
{{> organisms-footer }}

(译注：模板中既有组织也有分子，如果有必要也能包含原子，按照我实际开发的经验来说，简单的页面也可以就做成一个模板，如登录页，这样不同项目可能就改改背景图和样式，但是复杂的页面还是不要直接用一个模板去生成，原因我上一章也说过，不利于团队维护)

带有代码视图的内幕外观

模式库的一个常见功能是能够在内部窥视并查看组成特定组件的基础代码。公开UI模式的代码可以加快开发时间（我喜欢复制和粘贴下一个编码器），并且可以帮助团队负责人实施代码语法和样式约定。当大量开发人员在组织的代码库上工作时，这尤其有意义。

包含前端代码会使作者更加一致地编写它，但这并不能保证完美。开发人员仍然有回旋的余地，编写松散，不一致的代码，这就是为什么某些团队超越并建立了极其复杂的设计系统的原因。像Lonely Planet这样的公司已经实现了模式库的圣杯，也就是说，它们的模式库和生产环境是完全同步的。

这种传参方式已经有现在组件传参内味了

通过此设置，核心开发团队可以为所有模式的前端代码维护单一的事实来源。对于开发人员来说，模式库只需要提供包含特定模式的代码即可。

Pattern Lab提供了查看模式的基础HTML和用于生成HTML的模板代码的功能。它也可以扩展为展示随附的CSS和JavaScript代码。

最终，无论你决定使用哪种模式库工具，都应具有某种形式的代码视图。也许更重要的是，你创建的模式库应该展示使你和你的开发团队尽可能有效的代码类型。

给每个人自己

在选择工具来创建模式库时，你应该对有效模式库的以下特性和功能保持警惕：

• 提供模式描述和注释。
• 展示相关的模式HTML，模板，CSS和/或JavaScript代码。
• 查看整个分辨率范围内的图案。
• 展示模式变化的功能，例如活动或禁用的选项卡。
• 将真实的代表性内容动态添加到模式结构中的能力。
• 提供上下文信息，例如组成特定组件的模式以及使用该组件的位置。

归根结底，这与我们用于创建模式库的工具无关，而与我们如何使用它们有关。创建和维护有效的设计系统意味着极大地改变团队的文化，流程和工作流程。

小结：这一章以Pattern Lab这个工具为我们讲述了一个模式库需要有什么功能，其实现代web开发中的ui库已经做得很好了，如element，antd，他们的文档中已经有了详细的代码和使用说明，而且也有按需引入功能，文中提到的这种工具集更多的是在我们自己编写自定义的公共组件时可以参考参考。通常我们编写项目的公共组件时，需要有详细的注释说明，首先要写清楚这个组件是用来做什么的，第二要写清楚每一个props的类型和作用，最后最好有一个引用的示例，这些我也是从mint-ui的组件源码看到的。如果组件的props参数过多，最好是写一个markdown文件，反正现代的webpack编译也不会去处理你的md文件。

下一章 【译】原子设计4——原子工作流（节选）
译文目录在这里： https://www.jianshu.com/nb/47456777