背景

去年下半年，我在微信书架里加入了许多技术书籍，各种类别的都有，断断续续的读了一部分。

没有计划的阅读，收效甚微。

新年伊始，我准备尝试一下其他方式，比如阅读周。每月抽出1~2个非连续周，完整阅读一本书籍。

这个“玩法”虽然常见且板正，但是有效，已经坚持阅读六个月。

已读完书籍：《架构简洁之道》、《深入浅出的Node.js》、《你不知道的JavaScript（上卷）》、《你不知道的JavaScript（中卷）》、《你不知道的JavaScript（下卷）》、《数据结构与算法JavaScript描述》、《WebKit技术内幕》。

当前阅读周书籍：《前端架构：从入门到微前端》。

架构设计：组件化架构

如果一个页面的逻辑过于复杂，那么我们会将其拆解为多个子页面、模板、组件等，其表现形式是基于组件（Component-Based）的架构，又称为前端组件化。

前端的组件化架构

从前端来看，组件可以被视为构成用户界面的一个小功能，其表现形式是组件库，而组件库的作用是，通过复用已有的组件来快速构建UI应用。从UI设计来看，单单只有组件是不够的，还需要关注它们之间的配合。

组件化具有一系列的优点：可重用、代码简洁、易测试等。在这个过程中，它将一个页面的单一MVC架构拆解成了多个组件MVC+一个页面的MVC架构。

在这个过程中，我们主要通过组件的发展过程来学习相关的内容：

• 风格指南（Style Guide）。早期侧重视觉，对设计的文字、颜色、LOGO、ICON等设计做出规范，产出物一般称为Guideline, Guideline通常是UI规范。
• 模式库（Pattern Library），即UI组件库。模式库更侧重于前端开发，对界面元素的样式进行实现，其代码可供预览使用，产出物一般称为组件库UI框架等，如Bootstrap库。
• 设计系统（Design System）。设计系统在某种程度上结合了风格指南和模式库，并附加了一些业务特别的元素，并且进一步地完善了组件化到页面模板相关的内容。

上述三种类型，仿佛是前端三个不同时期的设计的演进。首先，设计人员设计出系统的UI图，由前端开发人员来实现。为了统一设计风格，我们制定了一套规范，即Style Guide。然后，为了统一相互之间的代码，我们又创建了UI组件库。最后，为了统一开发人员之间的语言，我们又创建了设计系统。

基础：风格指南

风格指南（Style Guide）通常是指，用于文档编写和设计的标准，或者用于特定出版物、组织或领域的通用用法。前端风格指南是UI界面中所有元素的模块化集合，以及实现这些元素的代码片段。设计人员可以根据风格指南设计出符合系统统一风格的页面和UI。风格指南只是一份索引——设计、组件的列表，该列表内容如下：

• 其展现形式，通常是以网站的形式来展现的。
• 设计人员，通过风格指南来查找对应的设计准备及常见的UI样式。
• 开发人员，从风格指南上直接复制风格的相关代码。

重用：模式库

模式库与面向设计人员为主的风格指南略有不同的是，它是一个面向开发者视角的组件库、代码集。其作用是，帮助开发人员创建易于维护的代码库。模式库具有一系列的优点：

• 开发效率。只需要通过参数便可以复用先前编写的代码，而不需要重复写代码。
• 一致化。减少了重复编写样式和组件带来的不一致的问题。
• 可维护性。通过重用与抽象减少了重复代码的出现率，代码量的下降也进一步降低了系统维护难度。

模式库和组件库，是一个容易混淆的概念，它们是包含的关系。从名称上来说，模式库包含了项目、应用程序中的所有可重用元素，如组件、通用代码等；而组件库只包含应用程序中与组件相关的代码。这一点十分有趣，在社区上我们看到的组件库多数是以组件为核心的UI库，而在项目内部落地的时候，为了方便维护，组件库中不仅包含了组件库，还带有一些常用的与组件相关的处理逻辑。

进阶：设计系统

设计系统是一组相互关联的设计模式与共同实践的结合，以连贯组织来达成数字产品的目的。模式是重复组合以创建界面的元素，如用户流、交互、按钮、文本、图标、颜色、排版、微观等。实践则是选择、创建、捕获、共享和使用这些模式的方法，特别是在团队中工作时。

设计系统从本质上来看是规则、约束和原则的集合，其分别由设计和代码实现。从名称上来看，更偏向于设计为主的体系。从开发人员的角度来看，它是一个尝试解决设计人员的交互一致性的系统。从设计人员的角度来看，它是一个规则的合集。

于是设计系统做的第一件事，便是加入风格指南和模式库，然后明确提出了设计原则及模式。

这时，设计系统包含了完整的设计标准、文档、原则及工具包（UI模式和代码组件）。这一系列的原则和规范，包含了如下的一些指南：

• 动作（Motion，即包含过滤和动画设计等）。
• 无障碍。
• 内容原则。
• 信息架构。

设计系统是一个开发人员与设计人员协作的产物。建立一个设计系统，意味着建立一个规则、一套规范，需要大家共同遵循这些规矩。设计人员拥有自己的与设计相关的术语，开发人员也拥有与自己开发相关的领域知识，在这个系统中需要融合这两者，建立出一个共享的、通用的语言。

跨框架组件化

过去我们谈论前端的组件化架构时，通常指的是框架限制的组件化架构。而当拥有基础的UI组件库时，我们的架构则是基于UI组件库的组件化架构，两者间的不同在于共性的第一次提取。当我们在业务组件的基础上，对一些通用业务组件进行封装时，我们的架构则基于UI组件库和业务组件的组件化架构。不论是哪种方式，最后都限定于框架限制——将系统绑定在框架上。

对于团队的技术决策者来说，绑定框架的实现是一种冒险的做法。未来，这些都是风险，那么有没有可能将底层的UI组件库、复合组件和业务组件库通用呢？

框架间互相调用：Web Components

不同的框架开发方式不同，导致不同前端框架之间的组件不能一起使用。即使用React开发的组件，也很难直接用在Angular的应用上。同理，Angular的框架也难以应用于Vue应用中。好在这些应用都可以开发成一个Web Components（Web组件），我们可以在其他框架里引用这些组件。

Angular框架提供了一个createCustomElement的接口，可以直接将组件定义成Web Components组件。而在React、Vue框架中，则是可以支持引入这些Web Components组件，也可以引入其他框架的组件。不过直接使用Angular构建出来的组件，体积上稍微大一些。一个更合适的方式则是，使用第三方框架来构建Web Components组件，如Stencil，然后在我们的框架、应用中引入这些组件。

跨平台模式库

有了上面的技术基础，我们就可以构建跨UI框架的组件库了，它可以解决在构建内部UI库时面对不同技术框架的问题。那么，为什么还没有这样的UI库？原因主要有两个：

技术不够成熟。现有的前端框架对于Web Components的支持并不是很好，比如，笔者尝试使用React时遇到一些问题。并且，既然前端框架都能支持构建出这样的组件，那么也需要浏览器对于Web Components的支持。我们需要比如custom-elements-es5-adapter.js等的支持，而像Polymer这样的Web Components框架也需要IE11+等浏览器的支持。

Web Components技术重写组件不够好。是的，我们需要将之前使用TypeScript、JSX或者．Vue编写的组件，换成更轻量级的框架。UI框架中的很多要素，是我们在编写组件的时候不需要的——我们只在需要的时候引入我们所需要的组件即可。

一旦包含浏览器支持的基础设施得到了进一步的完善，我们就能开发出这样的跨平台组件库。

总结

组件与设计之间的关系是相辅相成的。风格指南、模式库和设计系统，都是开发人员和设计人员在合作过程中探索的产物，每种类型都各有特点。

此外，本文还介绍了如何去创建对应的风格指南、模式库及设计系统。通过这些实践和练习，我们能从中找到适合于大型组织的开发人员和设计人员的协作方式。最后，介绍了如何通过Web Components在不同前端框架间相互调用组件，以证明跨框架组件的可能性，它可以进一步降低大型组织中多个框架下的组件开发成本。

作者介绍
非职业「传道授业解惑」的开发者叶一一。
《趣学前端》、《CSS畅想》等系列作者。华夏美食、国漫、古风重度爱好者，刑侦、无限流小说初级玩家。
如果看完文章有所收获，欢迎点赞👍 | 收藏⭐️ | 留言📝。