佳应 App 组件库构建

佳应 App 的组件库做到第三版，这一版我重新整理了组件的分类方式，并把每个组件的文档结构统一成固定的四块。

佳应 App 是驾捷乐面向汽车后市场门店的管理工具，门店日常的开单、会员、库存、营销都在上面跑。功能多，迭代快，设计侧如果每个页面都从头画，同样的按钮能画出七八种圆角。组件库要解决的问题就是这个。

组件怎么分类

这一版把组件分成六类：通用、系统、导航、输入、展示、反馈。

分法按用户操作的性质来。通用类是最基础的元件，按钮、按钮组这些哪里都用得上。系统类是平台自带的，状态栏、导航栏、主页指示器，样式不由我们定，但画稿时得有，不然设计稿和真机对不上。剩下四类对应用户的一次完整操作：导航是「去哪」，输入是「给数据」，展示是「看数据」，反馈是「操作之后看到什么」。

一个组件归哪类，看它的主要行为。比如底部选项卡，样式上它和标签栏、菜单栏长得有点像，但它是切换一级页面的，所以归导航。归对了类，后面找组件的人才知道去哪一页翻。

每个组件写清楚四件事

这一版统一了组件文档的结构。每个组件一份文档，固定写四块：一句定义、用途、类型示例、交互说明。

定义只写一句，说清楚这个组件是什么。按钮的定义是「展示一定数量的内容，提供与展示内容相关的入口及跳转」。用途回答什么时候用它、什么时候不用。类型示例把所有变体画出来摆在一起。交互说明写清楚操作之后发生什么。

定这个结构是因为之前的文档写法不统一。有的组件只画了样式，没写用途，用的人不知道这个场景该不该用它；有的写了用途没写交互，开发不知道点了之后跳哪。四块固定下来，设计和研发看的是同一份东西。

状态要枚举完

类型示例这一块，要求是把组件的所有状态画全，不能只画最好看的那个。

按钮在移动端有三种状态：常态、按压、不可点击。三种都要画，按压态经常被漏掉，但它是用户点下去那一瞬间的反馈，少了它界面会显得没反应。弹窗按用途分成提示、确认、图文、拓展四类，每一类下面再把无标题、有标题、增强、延时这些变体列出来。

枚举的意义在于把选择提前做完。用组件的人不用临场再设计一遍「这个弹窗要不要标题」，直接从已有的变体里挑。变体里没有的，才需要考虑是不是要新增。

极端情况单独算一类

缺省页放在反馈类里，和 toast、弹窗、加载并列。

它不是某个组件的附属状态，是页面级的东西。数据为空、暂无结果、网络异常、暂无权限、维护中，这五种场景每个页面都可能遇到。如果不单独定义，每个设计师遇到空页面就自己发挥一次，最后同一个 App 里出现五种画风的空页面。

文档里给每种场景配了固定的插图和文案结构。插图控制在内容区域内，周围留白，下面跟一句说明，需要行动引导的加一个小按钮。文案要说明当前是什么情况、能怎么解决，不能只写「加载失败」四个字。

视觉规范

组件之外，视觉规范单独一章，管颜色、文字、图标、阴影四样。

颜色分两个维度整理。一个是类型，主色和辅助色，主色是品牌黄，辅助色包括成功、警示、错误这些功能色。另一个是使用，文字色、背景色、状态色分开列，文字色按重要程度分级，从标题到辅助说明一共四档。

状态色单独列出来，是因为同一个按钮在常态、按压、禁用下的颜色不一样，这一组颜色要成对定义，不然按压态容易被随手调成一个「看着差不多」的深色。

最后

这一版一共六类，41 个组件。每个组件的文档末尾标了更新时间和负责人，谁改的、什么时候改的，翻文档就能看到。