组件化对于设计师来说，已经不是一个稀奇的概念了。加之今年很火的Atomic Design原子设计理论，更为加深了大家对于组件化的认知。

       

简单的说，组件化即是将业务场景中的常用模块进行元素拆解、再归纳整合为一套「多维度」的解决方案，它可以包含视觉、交互、动效、开发甚至是更多的内容。

至于为什么要组件化、组件化的好处，已有很多文章解释说明，这里就不一一赘述了。今天我们来聊一聊关于组件化，正在发生的事。

Sketch仍是组件化首推利器，拥有丰富的组件化插件

Sketch的Symbol与Library功能就是为了组件化而生，如今打开各大组件库的官方资源：Atlassian、Ant Design、Material Design、Apple Human Interface Guidelines（有提供PS）都是Sketch格式，你就会发现Sketch在组件化上是如此的强势。

其实PS的库功能也能作为组件管理来用，但在实际使用体验上更偏向于存储器，所以并不推荐PS来做组件化的设计。而Adobe的XD在增加了“符号”和“响应式调整”之后，也能满足一些组件化的需求，但相较于Sketch，XD在符号的复用延展上还有不足。

       

而Sketch不仅本身对组件的复用有很好的支持，不少开发者也提供了优秀的Sketch插件，这让组件库使用起来更加的方便。除了大家已熟知的zeplin、Sketch Measure以外，这里还给大家推荐一些实用的插件。

Sketch Symbols Manager

批量给Symbol重命名、以及管理Symbol文件夹的插件。在面临成堆的Symbol需要统一重命名时，简直不要太好用，需要花费 $9.99。

 

· Keep your symbols clean and tidy.

· Easily rename symbols and symbol folder

· Drag and drop your symbols from to folder to folder

· Create new folders

· Find unused symbols

· Delete symbols on the fly

Rename it

同样是一款重命名的插件，但是主要针对的是图层与画板的批量重命名，选中你想要批量重命名的图层或画板，打开插件输入名称就可以完成，再也不用一个一个去改了。

如果需要一些特殊的命名方式也是可以的，例如图层1，图层2，图层3...这种序列的命名，只要在名称后方输入规则就能轻松搞定。                  

命名的基本规则就是：名称+关键词，关键词有可能会忘记没关系，它在插件中会给到快捷选项直接选中keywords输入。

· ％n 按升序编号序列

· ％N 按降序编号序列

· ％A 按字母序列

· ％nn 顺序命名01,02,03...

· ％a 按小写字母序列

……

Sketch Palettes

针对文档色板的插件，支持导出文档色板、载入文档色板、一键清除文档色板。导出的色板格式为.sketchpalette，你可以把这个色板文件给到其他人使用。如果你有Layer Style以外的颜色需要同步，可以选择这个方式。

       

Axure RP

Axure官方的Sketch插件，介于大部分的产品都在使用Axure作为原型制作工具，为了让组件库能够在整个产品流程上打通，Axure RP插件支持将Sketch的文件，转换为Axure的文件。不过目前的版本转换后会导致一些组件的嵌套丢失，还不是特别的稳定但可以满足一定的需求。

       

不是所有的项目都要组件化

既然组件化那么方便，是不是所有的项目都要组件化呢？不是的。

人不能盲目的跟风，项目也不能盲目地组件化。弄清楚组件化对于项目的意义，再来决定需不需要组件化，毕竟组件化是一件牵一发而动全身的事情。

那什么样的项目适合组件化？组件化的时机是什么时候呢？

从项目的发展阶段来看，由0到1的新项目，因为面临着大量的调整与迭代，短时间内可能变化过大，不建议在一开始就进行组件化，这样不仅会限制产品发展的可能性，而且会因为组件化的搭建前期耗时过多，导致事倍功半。这样的项目，一般建议是在项目复盘之后，再进行组件的抽离和整理。

而发展相对稳定，或者说发展比较典型的项目，就很适合组件化，比如企业级中后台的项目。这样的项目甚至在团队成员都有组件化经验的情况下，一开始就能适当地进行一些组件化的布局。

组件规范追求规则与多样化共存，逐渐告别「生搬硬套」

为了能够更好的支撑多种业务，提供更多有可能的解决方案，组件规范不能制定得太死，需要有一定的延展性和灵活性。

1. 采用计算公式来制定规范

计算公式被运用来制定规范并不是一件惊奇的事，在页面布局上已有很多案例。如 The 8-Point Grid System（8点栅格系统）、Bootstrap框架等等。而现在计算公式不仅在布局上被普遍运用，也被用来进行配色和排版。

下图为我们在为大数据团队设计后台时，由于图表数据需要根据项目数进行自动增减，而这个增减的值是不确定的、多变的。所以我们不可能每增加一个数据就进行一次人工配色，于是在沟通协商后，我们决定采用一次函数来解决这个问题，最终实现图表自动配色，并且配色能够有规律的过渡。

       

当然这不是唯一的配色方案，大家可以根据需求，和开发团队探讨更多的实现方法。

（此处推荐一个颜色转码工具——hslpicker，能够十六进制颜色转换为HSL颜色）

其实使用计算公式来作为一些规则，说得抽象一点，是采用「规律」来制定规范。因为越是接近自然规律的事物，给予用户的体验就越真实。

2. 更多可定制样式，根据品牌调性定制主题

众所周知，组件库是被使用在多个产品中的，但不同的产品，想要表达的调性是不同的。所以在组件库的设计上，如果只有一种风格样式的话，就没有办法很好地契合更多的产品。针对这一点，很多组件库选择了将部分组件样式提取出来，比如说按钮的圆角、输入框的描边、卡片的阴影等等，通过给用户自定义这些组件的参数，以达成定制主题的效果。

这样的定制更加强调品牌与组件的结合，而不是让大家一味的套用规范。像Material Design在今年一直强调的Brand expression，以及推出的Material Theme Editor 材质主题编辑器，让各个产品在使用组件进行搭配的同时，能够和自身的品牌融为一体，可编辑的自由度也更高，风格也更加丰富。      

  

组件化在解决问题的同时，也会遇到新的问题

1. 项目成员缺少组件化的意识，或不合理的搭配组件

一个组件在使用中是需要考虑到场景的。但有时由于项目赶时间、或者是考量不够全面等其他原因，将“某个组件使用在它不应该出现的地方”这种事情，也是会发生的。这就是为什么需要在规范里给每一个组件的都写上使用说明，或者推荐方案。

       （图来自我们自己的组件库：提供两种输入框样式，一般推荐使用矩形输入框）

这样可以在一定程度上，让组件化意识比较薄弱、或刚接手项目的人员，能够正确地理解具体组件的用途和用法。

甚至可以提供典型的场景模版，给他们直接进行套用。

       （图来自Ant Design Pro，直接将常见的业务场景制作成了可视化的模版）

2. 遇到组件大版本升级时，项目面临过渡期

组件是需要维护和更新的，往往在项目中使用的组件版本，总会低于组件库的版本，这就涉及到项目升级组件库的问题。小版本的升级，大多是设计样式细节的修改，不会影响到项目的功能性；但是大版本的升级，由于增加了许多功能、甚至是改变了交互方式等等，在升级时会导致一些BUG。

     

所以如果项目需要进行组件大版本升级的话，如果不是有特殊的原因，应该尽量避免强制性的整体升级，建议采取过渡升级的方式。而在此过程中会面临着新旧版本共存带来的体验差异，可以考虑做一些预告，给用户一些准备，让组件平滑过渡。

3. 现有组件库无法满足新的业务需求

组件库不是万能的，通常遇到无法直接采用现有组件库解决的问题，如果微调某个组件就能够满足新需求的话，我们会视为是给该组件增加了一个拓展形态，并将此形态快速地增加到组件库中。

就好比下图，我们需要在用户进行下拉选择时，增加一个快速编辑和快速删除的入口，最后我们选择在选项的后方置入图标来解决这个问题。这就是通过微调来新增了下拉选择组件的拓展。

       

而如果微调无法满足需求，我们就会选择新增组件的方式，但新增的组件可能在其他业务里的适用性并不高，就暂时不会加入到组件库中，而是作为一个案例放在总结池。如果复现的几率增加，会再考虑是否加入到组件库中。       

组件化工具的创新探索，正在路上

回想组件化的初衷，无疑是想要减少不必要的重复性工作，提高工作协作效率，解放生产力，让我们能够聚焦于更有价值的创造上。在组件库之后，已经出现了更多的方式在加快组件化的进程。

1. 设计、开发的资源双向协作管理

项目资源的更新与迭代是设计与开发共同协作的事，但就目前的协作方式来看，设计资源与开发资源都是独自分离的，也无法做到实时的可视化双向映射。所以在资源管理上，其实很需要一个设计师与开发能够共同协作管理的方式。

就这个问题，现在也看到了很多团队正在进行探索，比如Airbnb针对动效的Lottie，以及React Sketch.app、还有Views tools等等。

       

React Sketch.app是以“用代码绘制组件”为角度出发的产品，是采用从代码编辑器渲染到Sketch的方式，是单向的。实际上设计师去进行使用的话，需要有一定的代码基础。

     

Views tools需要设计师使用它本身的App做设计，对于使用ps、sketch的团队并不适用，毕竟资源的迁移很耗时费力。

2. 跨平台组件库与组件化工具，构建组件化体系

单纯的组件制定对于很多团队来说，已经是家常便饭了，组件库也从PC发展到Mobile，未来甚至延展到VR，组件从静态走向动态，从二维走向三维。值得一提的是，在基于自身的组件库的基础上，各大平台也推出了自己的Sketch工具集。

1）Kitchen

在续加入 iconfont、Ant Design之后，今年10月，Kitchen 又新增了Ant V 的可视化图表生成器，再加上Kitchen本身支持将设计稿上传至语雀的画板进行标注说明，这一整套的设计流程就在工具集中完成了。可以说，Kitchen已经逐渐在Sketch内构建起了一套自己的组件化体系、组件化解决方案。

                                

2）Dapollo

针对移动端设计的工具集，它与Kitchen都能够支持iconfont的图标，但有所不同的是：Kitchen工具集目前并没有提供业务模版，还是用组件自由组合的方式来给到用户使用。而Dapollo直接提供了界面模版，拖拽到画板就可以使用，免去了一些布局的搭积木时间；同时使用该组件库的组件，能够对应生成代码。

3）Material Theme Editor

上文中提到过的Material Theme Editor，这里就不再重复介绍了。

               

当然，未来还会有更多基于组件化去做创新的产品，让我们一起期待一下吧。