前端 UI 组件,目前流行的实现方式大多源自传统客户端的 UI 设计体系。无论是早期的 Bindows,还是近几年兴盛的 ExtJS,其 UI 组件都在模仿客户端软件,代码实现建立在复杂的继承体系上。好处是可以构建出和客户端体验一致的一整套 UI 组件,但弊端也很明显:组件长得都差不多,代码则继承太深,牵三挂四,不够轻便。
如何才能让前端 UI 组件轻便灵活起来呢?首先得意识到 Web UI 设计有自己的独特性。Web 页面可分为两种:一种是以展现信息为主的 Web 页面(web page),另一种是以操作信息为主的 Web 应用(web app)。对复杂的 Web 应用来说,可以采用 ExtJS 等类库来构建类客户端体验。但是,越来越多的 Web 应用已逐步脱离模仿客户端的阶段,开始从 Web 的独特性出发,将传统 UI 组件的功能融入到 Web 页面中。
举一个例子:国内的 Web 邮箱,无论是 163 还是 QQ 邮箱,都会让人联想起 Outlook 或 Foxmail 等客户端软件。这种模仿成本很高,然而带来的效果个人觉得却不是很好。反观 Gmail,整体 UI 设计,简明轻快,但功能一点也不逊色。在 Gmail 里,看不到 Tree,看不到 DataGrid,脱离了这些传统 UI 组件的框框,将功能融入到 Web 元素里,反而让用户更自然、更高效。
前端 UI 组件的 Web 特性,需要我们打破传统思维,换一个角度,重新去思考 UI 组件的基本组成要素。换什么角度去思考?什么角度才是合适的?这离不开具体场景。下面以一个实例来说明。
在淘宝页面中,以下是几个常见的 UI 组件:
传统思路里,我们会构建三个组件来实现:
- Slide(轮播)组件
- Tabs(标签页)组件
- Carousel(旋转木马)组件
Tabs 组件,我相信任何一个前端开发工程师最多半天都能搞定,而且还能把延迟触发、动态加载等特性也给实现了。Slide 组件也不难。Carousel 组件看起来稍微复杂一些,但熬上一个通宵研究研究循环的实现,也不是什么大难题。
上面是传统思路。新思路是:我们真的需要分三个组件来实现吗?
仔细思索,我们可以提取出这三个组件的共同点:
- 都有一组触点(Triggers)。 Slide 的触点是数字,Tabs 的触点是标签头,Carousel 的触点是小图。
- 都有一组面板(Panels)。就是内容区域。
- 通过触点可以让面板切换(Switch)。
上面的几条里有一个很重要的概念:切换。所有这些组件的共同点是可切换的。如果我们实现了一个可切换(Switchable)组件,上面三种组件就都是特例了。
根据上面的抽象,很容易实现 switchable.js:
function Switchable(container, config) { … } S.mix(Switchable.prototype, { init: function() { } switchTo: function() { } next: function() { } prev: function() { } });
上面仅实现了基本的切换功能,我们可以进一步通过插件来实现更多功能:
plugin-autoplay.js
– 提供自动播放功能。plugin-effect.js
– 提供切换时的各种特效。plugin-circular.js
– 提供循环切换功能,比如 Slide 自动播放到第 5 张时,能无缝循环播放到第 1 张。plugin-lazyload.js
– 提供数据的延迟加载功能。
插件的实现在 JavaScript 这种动态语言里是小菜一碟。至少有两种思路,一种是埋好钩子(hooks),插件根据钩子进行扩展:
S.mix(Switchable.prototype, { init: function() { … S.each(Switchable.Plugins, function(plugin) { if(S.isFunction(plugin.init)) { plugin.init(); } }); }, switchTo: function(index) { … this.fire(‘beforeSwitch’, {toIndex: index}); … } });
在插件的代码里,定义好 init 方法,以及监听相关事件(事件可以看成是一类 hooks)即可实现需要增加的功能。
插件的第二种实现方法是动态修改基础对象,可以重写某些方法,也可以利用 AOP 特性,将增加的功能织入到基础对象中:
S.weave(function() { // plugin code }); }, ‘after’, Switchable.prototype, ‘init’);
上面的代码表示在 Switchable 的 init 方法执行完成后,再紧接着执行 plugin code。
通过这种方式,我们无需用到任何继承概念,没有 super,没有 extend,利用 JavaScript 的原生动态语言特性,就比较完美地解决了问题。
从 Switchable 的角度看,上面三个组件可以描述为:
- Tabs 是普通的 Switchable 组件。
- Slide 是可自动切换且切换时有特效的 Switchable 组件。
- Carousel 是可自动切换、切换有特效、可循环切换的 Switchable 组件。
来看下 Slide 的实现,变得非常简单:
var defaultConfig = { autoplay: true, circular: true }; Function Slide(container, config) { config = S.merge(defaultConfig, config); Slide.superclass.constructor.call(this, container, config); } S.extend(Slide, S.Switchable);
这里用到了类似 YUI 的 extend 方法,实现了继承,同时较好的保持了 JavaScript 的原汁原味。
可以看出,Tabs、Slide 和 Carousel 组件,彼此之间没有本质差别。封装出这三个类,仅仅是为了让开发者能方便快捷的调用(这些是高级 API)。对于资深开发者来说,在实例化 Switchable 时,通过传入不同参数即可实现所需效果(Switchable 是中级 API)。
更有意思的事情是,换一种思路实现代码后,也能帮助我们换一种思路看世界:
这个组件,可以看成是触点为图片的 Tabs 组件。左右两个翻页,无非是调用 next/prev 方法。进一步:
- Tabs 组件可以看成是仅有基本切换功能的 Slide。
- Slide 可以看成是触点悬浮在图片上面的 Tabs。
- 等等等等
最后会发现,这三个组件,本身就是相通的。原本同一物,何必分开实现呢?我们可以得到一个结论:
只要符合 switchable 可切换特性的 UI 组件,原则上都可以通过 Switchable 实现。 唯一限制的是您的想象力!
比如,在 Switchable 的基础上,我们可以进一步实现 Album(画报),实现 CoverFlow(仿 iTunes 的封面切换效果)等等。
上面对 UI 组件的思维角度是可切换(Switchable),这是一个形容词。进一步思考,我们还可以得到以下形容词:
- Draggable – 可拖曳的
- Positionable – 可定位的
- Selectable – 可选择的
- Sortable – 可排序的
- Stackable – 可堆叠的
- Clickable – 可点击的
- Ajaxable – 可 ajax 的
- …
在这种新思路下,前端 UI 组件的基本组成要素已不是 Panel、Memu 和 Button 等传统 UI 基础单元,而是上面这些形容词。假设我们要实现一个可拖曳的可动态加载数据的可排序的表格时,或许像下面这样写一行代码就实现了:
S.Widget(‘tableId’).draggable().ajaxable().sortable();
这是一个梦想。但有梦,去追,说不定就能实现。
备注
上面的代码里使用了 KISSY UI 类库,详细请参考: http://kissy.googlecode.com/
Switchable 的详尽代码实现请参见: http://kissy.googlecode.com/svn/trunk/src/switchable/
作者简介:王保平,前端架构师,网名射雕,花名玉伯。崇尚简洁而不简单,相信付出才有收获。就职于淘宝网 UED 部,忙并快乐着。个人博客: http://lifesinger.org/ 。
本文已被收录在《架构师》(5 月刊)。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。
评论