聊聊前端 UI 组件：组件特征

本文是文章系列「聊聊前端 UI 组件」的第二篇，内容与本系列的上篇文章《 聊聊前端 UI 组件：核心概念 》有所关联，如果还没看过，建议去看下。

本文的主要内容是根据特征对前端 UI 组件进行建模，让我们尽可能充分地了解它的方方面面，并为如何设计以及建立一个组件体系打下基础。

组件构成

一个完整的具备功能的 UI 组件的构成，有结构（structure）、表现（presentation）和行为（behavior）这三个方面。为什么强调是「完整的具备功能的 UI 组件」？是因为它是一个最全的特征集合，而其他的「UI 组件」可能会缺少一些特征，从而使分析不那么完善。

看到「结构」、「表现」与「行为」这三个词，作为一名有经验的前端开发者，很自然地就会想到很久很久之前开始一直提倡的前端开发的关注点分离——HTML 负责组织页面结构，CSS 负责网页内容的表现样式，JS 则负责用户与网页之间的交互，它们各自扮演着不同且相辅相成的角色。

关注点分离

然而在这里，它们的含义会有所不同——

经 HTML 组织后的网页内容是「结构」没错，但它仅仅是代码层面的，未被 CSS 所影响的结构。最终的视觉呈现，也就是视觉层面的「结构」，应该还包括 CSS 的布局类样式，如定位（positioning）、浮动（float）等。

CSS 中的那些非布局类样式，如颜色、字体、文本、边框、尺寸、留白等类别的样式，以及图标、图片，皆为「表现」。这些一般还被称为「主题风格」或者「皮肤」。

可在 JS 中运行的事件系统以及进行逻辑处理的函数和对象方法，算是「行为」——这就是 UI 组件的交互逻辑了。当然了，与交互逻辑相融合的业务逻辑，也是「行为」的一部分。

易变性

根据构成 UI 组件的每个部分的性质，会影响 UI 组件相应部分的易变性——对于组件复用来说，该部分是相对稳定的还是相对不稳定。

GUI 发展了几十年，人机交互的图形元素及布局方式已经相对固定，只要不是出现像 Google Glass 之类的革命性交互设备，就不会发生重大改变。

如上所述，未来到底会出现什么样的变革性交互方式无从得知，但我认为，只要是需要用眼去看且用手去操作，交互方式就逃不离这几十年来未有啥变革的形式。因此，UI 组件的视觉结构和交互逻辑是最不易变的，且无论是交互模式还是触发事件都是可枚举的。

如果单纯从最终的 HTML 结构上来看，它也算是不易变的，但在现代前端开发中，HTML 的结构基本是动态生成的，并且强依赖于 React、Vue 这类没有统一标准的 JS 库/框架。另外，还存在着像 WXML 、 AXML 这类平台限定的视图结构描述语言。由于写法不一致，这就使页面内容结构变得不那么稳定。

一般来说，离用户越近的东西越容易发生改变。在网站、应用中离用户最近的是 GUI，而在 GUI 中离用户最近的则是主题风格，这是对用户来说最直观的东西。主题风格会随着 GUI 设计人员（通常是设计师）的审美和想法而改变，所以它是最易变的。

因为业务逻辑是进行业务相关处理的核心所在，如果业务规则变了，相应的代码实现也得跟着改变，所以业务逻辑也是很易变的。业务逻辑对于一个网站、应用来说是十分必要且重要的，但对 UI 组件来说，它就没那么必要了，更谈不上重要。在前端的 GUI 层面，业务逻辑理应是交互逻辑的延伸。

为了方便，将 UI 组件各个构成部分的易变性及其影响因素整理如下：

构成 易变性 影响因素 结构 视觉结构 不易变 内容结构、布局类样式 内容结构 较易变 生成 HTML 的 JS 库/框架的源码、平台限定的视图结构描述语言 表现 主题风格 很易变 GUI 设计人员的审美和想法、非布局类样式、图标与图片 行为 交互逻辑 不易变 交互设计人员的想法 业务逻辑 很易变 业务规则

从表格中可以看出，将「易变性」分成了三个等级，按照从小到大的顺序来分别解释下：

• 「不易变」——受交互方式影响，只要没发生什么革命性改变时就不太会变；
• 「较易变」——受源码语法影响，只要源码的编写方式确定就不会变；
• 「很易变」——受业务和人影响，只要业务领域、业务规则还有人的想法不变就不会变。

组件分类

从一个 UI 组件的内部是否还包含其他 UI 组件这个角度来看，分为「原子组件」和「复合组件」两类。「原子组件」是不可再分的 UI 组件，即其内部不再包含其他的 UI 组件，像按钮组件、图标组件、分割线组件等；「复合组件」则是由一个以上的原子组件所构成的，如导航菜单组件、选项卡组件、对话框组件等。

根据 UI 组件的适用性，可分为「通用组件」和「专用组件」。「通用组件」是能够满足大部分常规场景的 UI 组件，它们的集合通常会作为「组件库」整体打包发布为一个软件包；「专用组件」是为了解决某些特殊场景需求而存在的，像 spreadsheet、各种编辑器等，这类一般都是单独发包。

[按照作用分类]

继承关系

不像面向对象编程中的继承那样是行为的复用，这里所说的「继承」是指表现的复用，并且还能够「多重继承」。

在继续往下之前，先引入一个「虚拟组件」的概念。正如它的名字所示，是一个虚拟的，实际不存在的，只是概念上的组件。它是几个主题风格属性的集合。

输入框组件、下拉列表组件等都属于 表单控件 （form control），它们都继承自「表单控件」这个虚拟组件，如果各自没有指定颜色、字体、边框等主题风格属性的话，将会按照虚拟组件中所设定的来显示。类似地，下拉列表组件、下拉菜单组件等都有弹出层（pop-up），它们都继承了「弹出层」这个虚拟组件。

想必你已经发现了，下拉列表组件同时继承了「表单控件」和「弹出层」这两个虚拟组件，这就是上面提到的「多重继承」。

那些所谓的「虚拟组件」，它们也遵循着同样的继承规则——如果自身没有指定特定的主题风格属性，则会按照父级所设定的显示。那么，虚拟组件的「父级」是啥呢？——是基础风格。

虽然这里所描述的继承关系看起来有点像 CSS 中的 继承 ，然而它们并不一样。

总结

TBD