为什么选择yui3。
因为他已经脱离一个库(library),更像一个platform。包含了loader,以及重新定义的类结构。
最明显的好处,就是以后不需要在页面顶部声明一堆的script src 了。这些都可通过javascript脚本配置
来实现 (yui3 的自动加载)。我没确定sina 现在的javascript是用谁家的方案(或者自产)。但是
应用loader这个理念已经是广泛验证了。(更不用说和yahoo关系非同一般的那些标杆性网站)。
而且,loader不是只针对js的。连css也可以load。
多个js文件造成的并发连接过多?
这个问题可以分开来看,在网站的环境下,由于是互联网,可以考虑combo。在企业系统中,
暂时可忽略这个问题。毕竟大多是局域网环境;而且分散的js,浏览器也会cache。(反而combo因为
是容易产生动态url去request,可能导致浏览器不得不去下载)。这是我现在的理解。
组件结构
把每个独立功能用类、组件的方式分拆出来,声明依赖,是个清晰的、可复用结构。
虽然用了一阵子的yui2。但是对yui2冗余的代码结构方式不太能接受,例如一个事务的绑定,也要
用YAHOO.util.Event.addListener(ele, "click", onContextMenuTargetClick); 这么长的代码。
相比而言,现在Y.on("click",func,ele);是简洁很多了。虽说可以对yui2做个声明来转换(
如:var Y.on = YAHOO.util.Event.addListener ) 但谁也不想从头梳理这些namespace吧……
所以用YUI3的很大一部分原因,就是他的ns变得简洁一些了。之前大部分用mootools来处理
js,现在已经在准备各类基础的组件,以期一次转换。以后只需要用:
<script src="http://yui.yahooapis.com/3.1.1/build/yui/yui-min.js" type="text/javascript"></script>
剩下的,全都是javascript,动态的去组织了。
最近还做了一项工作。
将yui2-menu (2.8.1) 作为组件引入yui3了。由于yui2-menu基于Overlay 。而yui3的Overlay已经做了重新定义。
因此只能把yui2的container-core引入(当然也做了一番调整)。
整个修改下来的感觉就是,其他的引用,大多可以通过compat.js来达到。但是……有个事情变了,就是Event的
处理方式。尤其是CustomEvent。
最大的区别是:
//假设this 是 A
this.event1.subscribe(this.onEventFunc,obj,this); //subscribe 是仿yui2写的,compat里面有转换
在yui2里
onEventFunc 可以取到 this = A
而yui3里
onEventFunc取到的 this 貌似就是 Event.target 。
这点令我困惑( 因为之前未解读过Yui2 Event 的原理)