编者按：如何构建组件库？本文总结了组件库的设置、需要用到的工具和同步方法，帮助您快速上手组件库设计。随着公司业务的不断壮大，组件化不仅为业务带来了一致的设计语言和工作效率的提升，也影响和改变了设计团队的产出和协作方式。GtechUED团队在进行需求设计的同时，逐步沉淀出一套适用于多平台、多业务的组件库，从而提升设计和协同效率，最终实现专业价值和商业价值的平衡。在本系列文章中，我将分享自己在组织和维护GtechUIKit（Mob）过程中的一些思考和方法。今天我们就来说说如何迈出元件库设计的“第一步”。一、关于组件库1、组件的本质是一条规则从某种程度上说，设计系统（DesignSystem）就是这样一条“规则”——配色、文字、组件等一系列设计元素。标准化体系为设计者提供决策指导。组件库作为设计系统的一部分，通过总结典型样式，封装常用组件，帮助设计师快速实现中高保真原型设计。遵循这样的“规则”，不仅可以有效加快设计进程，还可以提高设计模式的可重用性和一致性，使整体产品设计更具可扩展性，更易于维护。2.持续维护的意义组件库项目其实并不是经过一个周期的努力而交付的产品，而是经过长时间的业务需求迭代不断沉淀的产物。就像跑马拉松一样，从起点迈出第一步很容易，难的是坚持跑下去，最终到达终点。通常，业务迭代和组件维护的时间线是不交错的，每个业务迭代周期都会调用当前版本的组件库作为基础模板；同样，每完成一个迭代周期，期间内高复用的组件或样式定义也会被定义更新到库中。随着时间的推移，对于日常工作项目中的很多需求，你可以通过拖拽或者少量修改的方式快速构建页面。为了快速构建页面，组件库本身需要满足“合理性”，包括合理的结构、合理的命名等，而这些都需要在整理和维护的过程中不断思考和修正。在实际过程中，往往是在中间整理出某个组件时，似乎将其封装在另一个结构中似乎更合理，那么之前的结果可能需要推翻或修改；同时，元件库还应满足可复现性的要求。有用且易于使用的要求，以满足日常业务的需求。除了学习使用组件来提高工作效率外，设计师还需要尝试了解封装、命名乃至维护的方法和过程，这样才能更得心应手地使用组件。二、必要设置1、基本样式组件库由组件组成。样式是组件设计的基础，是通过从下到上的层次结构逐步构建的。在制作组件、模板、页面的过程中，首当其冲的是对基本样式的全面细致的定义和维护，包括颜色、容器、字体、图层等……以“字体”为例，文字构成界面信息，content基本要素之一，无论是在高保真设计阶段，还是对于处于线稿和低保真原型阶段的交互设计师来说。利用颜色、字号、粗细等不同的参数构建界面的整体和局部信息展示，保证界面内容的层次和气息，帮助用户更好地获取界面信息。针对系统级产品的通用场景，GtechUIKit(Mob)提供了360单个文本的通用样式，其中样式的命名规则是根据文本的显式属性来确定的，即“font”weight/fontsize/alignment/color”，如“Regular/14/1_Left/Grey6”，代表字重常规，字号14，左对齐，颜色定义为“Grey6”的文本。当然，在所有这些文字样式中，可能经常使用的并不多，但我们还是希望在前期花足够的时间和成本，定义一套统一的样式表，能够应对大部分的使用场景，增加后期维护组件库的容错性，满足组件库的易用性。2、组件结构“结构清晰”是组件定义的要求，也是考虑组件库易用性的因素之一。如果说组件库的最终目标是开源，那么在初期的整理和后续的维护中需要考虑的一个问题就是“通用”，即探索一种很好的适配和兼容的方式大多数团队和个人。易于理解、易于索引和调用的组件分类。经过调研和内部讨论，我们最终选择将组件库按照使用场景划分为6个模块，将各个典型组件分页展示。具体展示结构如下：当然，基于组件属性的分类也是一种常见的组织结构，AppleiOSUI或GoogleMaterialDesign等系统级组件都是按照组件属性来划分的，都是为了更方便的索引和呼唤。在设计上，只要能达到目标，通向目标的方法只需要选择最合适的即可。3.命名规则关于命名方法和规则，也是组件库组织和维护过程中的重要环节之一。无论是颜色、图层、文字样式的定义，还是组件、图标、典型界面的排列组织，统一、通用、灵活的命名规则是贯穿始终的基线。上文提到，组件是根据使用场景划分的，每个组件包含若干个组件，如“展示”场景中的单元格、标签、标识等，而每个组件又由若干个状态、参数等构成.层次结构对组件的命名有一定的要求。一方面，要让维修流程更加有序清晰。另一方面，要保证最终输出的组件易于索引和调用。通常，为了体现结构层次，我们在组件命名中使用“/”符号来分隔类别场景、组件、状态或其他参数（Sketch可以自动识别“/”符号并将其作为类别分隔符来组织层层叠加，最终形成一个完整的目录结构），比如下图“显示/标签/圆形标签/小标签”等。用户只要在调用时知道自己需要什么组件，就可以很方便地逐层索引。与组件结构一样，没有所谓的“最佳”命名规则集。最正确的规则在团队中充分讨论并符合大多数人的使用习惯，最终达成共识。三、工具与同步1、插件推荐《工欲善其事，必先利其器》。随着工作内容的不断丰富，很多操作往往需要设计师手动实现，难度大、繁琐；在Sketch社区中，不仅有众多的设计师，还有一个活跃的开发者社区。开发者提供了很多优秀的插件，从不同角度完善了Sketch的功能，提高了设计师的工作效率。在组织和维护组件时，我通常使用以下两个插件：FindandReplaceText用于在整个Sketch文件中查找并批量替换所选图层、画板和页面设置中的文本内容——无论是layer可以使用实际的文字内容或图层列表中的文字名称；在尝试命名规则的过程中，我们会使用该插件批量修改基本样式定义中呈现的文字样式名称。StylesGenerator用于批处理和自动定义文本和图层样式。确定命名规则并完成初始样式或字体属性设置后，选择所有示例对象并执行“生成共享样式”，Sketch会根据您选择的对象的图层名称自动生成相应的样式。无需任何手动命名过程。2.协同解决方案前面提到，组件库的组织和维护是一个跟随业务需求迭代更新的工作。适时的迭代优化可以让组件更好的满足当前项目的需求。在内部，我们通过思考现有问题并尝试找到最佳方式，让团队更容易高效协作。最终，我们决定将组件维护的工作流程“上云”，即设计协同工作上云；简单来说，这种工作方式就是把组件库Sketch文件放在云端，通过云账号的能力，大家可以同时共享和使用这个文档。该文件将包含设计规范、组件、典型页面等，设计人员可以在工作时直接调用这些。具体操作如下：通过iCloud云盘将组件库Sketch文件分享给团队设计师（可根据团队需要设置相应的编辑和查看权限）；元件库文件出现在分享好友的云盘中，可以添加到草图库中；即可以通过Symbol在工程文件中引用该组件；每当组内更新组件时，右上角会出现“库更新”推送，选择更新的组件即可。4.不仅仅是设计师。相信很多小伙伴也在努力梳理出一套标准的元器件规范，希望能够提高设计效率，保证输出的一致性。但在实际工作中，会出现一些问题：除了自己或设计团队使用组件外，前端页面似乎还没有达到组件化的效果，不同的开发者还是会重写代码每个组件，效率低下，同时视觉还原也比较差。造成这种情况的主要原因是代码没有在开发层面实现，组件只是一个设计稿，不是真正可调用的“积木”。因此，维护组件不应仅靠设计人员，开发也应是主要参与者之一。两者需要经过多次沟通、校对和持续开发维护（这里省略了很多协作过程，其实团队调度的协调是一个很重要的因素）。最终，我们输出的应该是一套可视化的产品和背后的实现代码，才能真正在代码层面实现拖拽组件构建界面的目标。总结在这篇文章中，我们主要讲了关于“如何设计组件库”的一些常见问题，比如组织和维护组件库的必要设置、插件和协作方案的推荐、组件编码等，希望能够为您的工作带来一些思考和帮助。
