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

Category:
发表:

这是一篇懒散的随笔,写作时,完全没有考虑到读者的感受,仅仅是作者对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!

终于唠叨完了。