UI组件库和静态服务域的相关实践

这是一篇懒散的随笔，写作时，完全没有考虑到读者的感受，仅仅是作者对UI和组件化等topic的一些胡思乱想。勿喷。

我一直觉得，一个有逼格、有深度的公司，应该在UI这块有自己的一套规范，无论是从0到1自己实现的也好，还是站在巨人的肩膀上。

人都有身不由己的时候，无论码农还是设计师们。在这样一个背景下，往往做出一些割裂的产品和设计。比如，UI风格混乱、交互风格混乱、特效混乱、代码混乱……

We need rules.

试想一下，如果你处在下图的工作场景中，

这里的Nyx即是我们的UI规范。

1，产品在产出需求原型时，在展示和交互部分，会借鉴参考UI规范。把合适的UI放在合适的原型展示上。
2，设计师们拿到原型后，参考UI规范，做出视觉稿。
3，前端开发在拿到视觉稿之后，使用UI规范的组件实现，快速实现。

Perfect!

这期间可能会有一些坑在里面，但是我认为这个思想和方向应该是没有问题的。

那么问题来了，我们该怎么做？

1，想好了，我们到底应该是站在巨人的肩膀上？还是自己要做巨人？这关系到，我们到底是选一套主流的UI作为底层基础UI，还是应该自己造一个。两种方案各有优劣，我个人倾向后者。因为我一个信奉拿来主义的人。
2，选好了底层的基本UI库之后，我们仔细研读，弄清楚它每一个部分。为什么需要这么做？一个字，避坑。
3，这时候需要我们的设计师兄弟上场了。前端开发们与之亲密合作，目的只有一个，那就是决定好我们到底需要哪些基本的UI。更进一步，我们还需要决定这些基础UI长成什么样子。基本UI的本质应该是一堆CSS文件。
4，好了，这时候我们已经有了基础UI了，这时候我们可以动一动组件的心思了。

有一个问题来了，什么是组件？组件跟之前提到的UI又是什么关系？

我的脑海里，UI指的是页面元素的表现风格，它是一套规范，它规定了页面元素应该如何表现自己。而组件是对UI规范的一种多样化实现。

举个例子来说，一个按钮的UI规范可能是这样的：是一个矩形，中间有文本，边界有边框，可以点击，点击的时候会有一种特殊的视觉效果，……

那么，与之对应的按钮组件，我们可以抽象出来很多参数，根据需求来自定义按钮的UI，并且把这些参数都量化成代码实现。

组件更多的内容，我们后面还会继续探讨。现在，言归正传。

5，我们现在有了UI和组件，我们可以做更多的事情了。我们以UI和组件为基础，搭建上层的静态域，为业务域提供服务。怎么理解这句话？

这里有一张图，

简单概括来说，我们会一个称之为静态域的东西，为所有的其他的业务域提供通用的UI和交互服务支持，包括但不限于静态文件分发、UI及组件化支持、通用页面版本支持等等。

所以，接下来让我们来具体的量化一下我们的计划。

0，准备阶段

1. 在做这些事之前，我们应该自问三个问题，为什么要做？解决什么问题？目标是什么？
2. 敲定底层方案的选型和实现方式。
3. 相关规范和计划的制定。

我觉得到文章这里，我们应该已经准备好了。

1，第一阶段

1. 基础UI的抽象及分类。
2. 构建底层的CSS基础代码。
3. UI的派生继承方式及实现。
4. UI多态化抽象。

关于UI分类，参考了很多前辈的成果，如下图

个人觉得按照这种feature的概念和维护队UI做分类可能更具延展性和拓展性。

关于底层CSS基础代码的构建，我觉得bootstrap是一个不错的做法，提供一个可供高度自定义的用户编译界面。

此阶段中，我们还会做一些UI多态化的工作。什么是UI多态化？举一个简单的例子，你是一个按钮。你可以是红的，你可以绿的，你还可以是黑的；你可以胖胖的，你还可以很苗条；你可以是高富帅，也可以是矮矬穷。

同一类的UI可以拥有不同维度的变化，比如颜色、大小、交互特性等等。

正式因为UI的多态性，给了我们丰满的UI展示。

2，第二阶段

1. 基础UI的动效及分类。
2. 实现UI动效（渐进增强）。
3. UI多态化实现。
4. 多终端支持

如果你的页面自带各种酷炫的动效，相比朴素的UI，你无疑会更加被人青睐。但是动效何其多，我们需要需要给不同种类的UI装备合适的动效，以达到完美契合度。本人是十分厌恶无脑滥用动画的。合适的就是最好的。

此外，我们在实现动效的时候，还有一个准则，就是渐进增强。而且全部都依赖CSS3，我们不会使用Javascript来操作dom来实现某一些动画效果，绝不。简而言之，那些不支持CSS3的可怜浏览器们，只能注定被扔在矮矬穷的阵营里面了。

此阶段中，我们还是把UI多态化的task做掉。一般来说，会有两种做法，一种是独立式的css实现方式，一种是堆叠式的css实现方式。比如，

<div class="btn-butcher"></div>
<div class="btn btn-green btn-large"></div>

两者都表示绿胖子。明显的，后者具有更强的定制化，更加灵活。

关于多终端。在这之前，我们都应该了解一下，什么是响应式设计（Responsive design，RWD）？什么是自适应设计（Adaptive design，AWD）？

举一个例子。一个页面，如果无论你如何的缩放浏览器的窗口大小，这个页面都会较好的展现。那我们就说这个页面是响应式的。
如果你用不同尺寸的设备去访问这个页面，它也能非常自如在不同的设备展现，此时，我们就说这个页面是自适应的。

• RWD：倾向基于Media Queries、Content-Based Breakpoint来改变页面适配不同的分辨率尺寸。
• AWD：倾向针对几种特定的分辨率尺寸做定制。可能会有好几套页面。

但是在有时候，他们又会相会渗透，配合使用。

3，第三阶段

1. 组件化实现方式的探索，如何组合UI和交互？
2. 构建基础组件及组件分类
3. 构建复杂组件及交互实现

前面已经说到了，组件是对UI的具体实现。UI是一套规范，要想将这一套组件转变成组件，我们需要思考一件非常重要的事，就是：如何将UI实现为组件？我的意思是，实现的途径是什么？

想要回答这一个问题，先得回答一个前提问题？我们怎么去定义一个组件？言下之意，一个组件，应该包含什么内容？

现下，普遍的一种观点认为，一个组件应该包含三部分，展现载体（模板）+ 视觉展示（样式）+ 交互特性（交互）这三部分组成。

基本上我们前面说的UI指代就是模板 + 样式。所以，我们现在还缺一点，我们如何给组件引入交互？

我们需要一个世界观去架构模板、式样和交互，让他们有机的组合在一起。我来看看react是如何做组件化的。

从图中我们可以看出，

1. 要有良好的类继承机制。
2. 需要方便的引入机制。包括引入自身的样式，也包括引入别的组件。
3. 需要一个接口对外暴露组件自身。

我们的组件化最少也需要从这三个方面考虑。或者我们完全可以采用react为实现载体也并无不可。

4，第四阶段

1. 什么是静态域？解决什么问题？
2. 静态资源分发，UI和组件支持。
3. 业务域中通用界面和操作的统一支持。
4. ……

所谓静态域，其实就是在UI库和组件化这两者较为完备之后，我们为了让UI和组件的服务输出更加智能和高效，从而搭建的一种上层应用。他的具体作用，我觉得这张图完全可以意传了。

除了静态资源分发，UI和组件支持这一点之外，业务域中通用的板块也可以使用静态域来做分发。举个例子，有一个管理中心的用户后台，这个管理中心是好几个业务线控制台的聚合体。它会有一个左侧导航菜单，每一个菜单对应各自业务的页面。我们在是实现上，可能会在每一个独立的业务域中都做一套这个左侧菜单，一旦某个菜单项发生更新，将会影响到所有包含这个左侧菜单的业务域。这无疑是一个很烂的方案。

假如我们静态域已经可以提供服务了，那么不同的业务域甚至只要调用业务域的一个js脚本就可以在各个业务域中生成左侧菜单了。

perfect!

终于唠叨完了。