关于软件设计:聊聊前端-UI-组件组件特征

本文是文章系列「聊聊前端 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 组件各个形成局部的易变性及其影响因素整顿如下：

从表格中能够看出，将「易变性」分成了三个等级，依照从小到大的程序来别离解释下：

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

组件分类

以较为形象的视角对 UI 组件进行分类——

原子性

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

通用性

依据 UI 组件的通用性，可分为「通用组件」和「专用组件」。「通用组件」是可能满足大部分惯例场景的 UI 组件，它们的汇合通常会作为「组件库」整体打包公布为一个软件包；「专用组件」是为了解决某些非凡场景需要而存在的，像数据网格、各种编辑器等，这类个别都是独自发包。

功能性

依照 UI 组件所起到的作用，大略可划分为以下几类：

这种分类形式没有一个严格的定义，就见仁见智了。

组件继承

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

在持续往下之前，先引入一个「虚构组件」的概念。正如它的名字所示，是一个虚构的，理论不存在的，只是概念上的组件。它是几个主题格调属性的汇合。

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

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

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

尽管这里所形容的继承关系看起来有点像 CSS 中的继承，然而它们并不一样。

总结

本文从前端 UI 组件的形成、分类及组件间的继承关系等角度登程，通过剖析组件的特色来探讨建设一个组件体系所须要关注的一些点。其中，UI 组件各形成元素的易变性是最应该被关注的，它会对组件体系的可复用性、可扩展性等产生很大影响。

本质上，HTML 与 WXML 和 AXML 等是同一级别的，都是平台限定的视图构造描述语言——WXML 是微信小程序的，AXML 是支付宝小程序的，而 HTML 则是「网页浏览器」这个平台的。

在动静网页中，尤其是应用了 Mustache、Handlebars 等模板引擎或 React、Vue 这类库 / 框架时，最终的内容构造根本是 JS 生成的，这就强化了 JS 而弱化了 HTML 在内容构造上的控制力。

各个 JS 库 / 框架的 HTML 代码生成形式不同，视图构造形容语法不同，没有对立的规范，这就造成了凌乱——这也是对前端 UI 组件的可复用性最大的挑战！

本文其余浏览地址：集体网站|微信公众号