yui3在框架设计中的牺牲和让步(2)

4、代码污染 or 沙箱

刚才提到的沙箱可以解决一部分代码污染的问题，新人阅读代码不用再看着乱码般的源码，“瞻前顾后”小心翼翼的寻找html和js的对应关系。但这种写法也存在隐患，现在的前端开发越来越复杂也更多的使用分层，比如底层使用yui，中间层是自定义的工具库，或者再加一个项目的widget组件库，写页面逻辑则是基于这些库进行开发。这样的话，每段逻辑可能写成这个样子：

<!–A逻辑的html代码段–>
<script src="widget.js" /><!–项目的widget库–>
<script src="logicA.js" />
<script>
$.onDomReady(function(){
___LogicA.start();
});
</script>

尽管我们可以约定，将项目用到的所有的组件都统一加载进页面中，但当组件越来越多的时候，就出现了上文所说的一步到位和颗粒化之间的矛盾，当每个控件单独占用一个js文件和与之相伴随的css皮肤，一个相对复杂的逻辑就变成了上文所说的手动引入js文件，并随之引入一些显而易见的弊端：

<!–复杂的A逻辑的html代码段，使用了日历，弹层，幻灯–>
<script src="calendar.js"/><!–日历–>
<script src="box.js" /><!–弹层–>
<script src="tabview.js" /><!–幻灯原型–>
<script src="slider.js" /><!–幻灯–>
<script src="logicA.js" />
<script>
$.onDomReady(function(){
___LogicA.start();
});
</script>

首先，手写大量的js文件会各自占用单独的http请求，在者，这个场景中，slider.js继承自tabview.js，因此要着重关注他们的顺序，第三，如果别人在页面的其他地方也使用了日历或者幻灯，还要再加两个相同的js标签？其实，说到这里，我们已经可以隐约看到大项目团队开发的影子了，在一个迭代及其频繁的项目中，开发者需要在短的时间内完成一个复杂页面的某个功能的开发，而且不能影响到页面的其他功能，毕竟，每添加一个功能，QA mm们都要将与之牵连的所有功能都要回归，可辛苦了我们的QA mm们。在这种情况下，一个功能的开发可能和同一个页面其他功能的开发相互并行。互相不属于同一个项目组，也不知晓对方的实现。这种模式则是我们经常遇到的多人开发，冲突也大都由此产生，每个功能单独看来是正确的，合并到一起会产生冲突和bug，这时调试bug则需要两个工程师同时进行，很麻烦。甚者，当组件升级了，比如，tabview.js再继承自tab.js，则又要去联系各个工程师，将每个引用tabview.js的地方之前再加上一个tab.js，很麻烦。我们说，这种多人协作模式所带来的冲突也是代码污染的一种，因为每个人只能掌控类似tms区块那么巴掌大的地方，所组成的最终页面是什么样，都不知道。更何况，这种生猛的引用js，也会阻塞页面加载，占用http请求，影响性能。

鉴于此，yui将js的动态引入机制也并入其沙箱设计之中，我要引用的只是一个名字，比如slider.js，他依赖tabview.js，tabview.js依赖tab.js，这样我只需引用一个名叫”slider”的东西即可，不用操心他依赖什么，更不用管如何引入到页面中，yui都帮我们搞定：

<script>
TB.addmoudle({
___logicA:{
______fullpath:'logica.js',
______requires:['slider']
___}
}).use('logicA',function(Y){
___LogicA.start();
});
</script>

当我们看最终组成的页面的时候，看到的只是埋藏在页面各个角落的这些简短的结构一致的js代码段。很易理解，这点代码也不用像长的代码块压成一行。（更多细节可参照 前端弱架构导致的代码污染 ）