experience about updating to kissy 1.3

[shuier]

提前研究kissy 升级指南：

1.1.6->1.2.0和1.2.0->1.3.0

loader

学习了解1.3的loader

1. 了解[1.3 loader]（http://docs.kissyui.com/docs/html/api/seed/loader/) ＊ 看完文档后，［Loader 使用示例］(http://docs.kissyui.com/docs/html/demo/seed/loader/index.html#loader-demo)注意combo支持方式
2. [KISSY Module Compiler]（http://docs.kissyui.com/docs/html/tutorials/tools/module-compiler/index.html）
   • 了解两种模块打包方式：模块依赖自动合并与模块依赖自动抽取
3. 下载kissy-tools安装包，地址：https://github.com/kissyteam/kissy-tools
4. 把安装包导入你的工程里面
5. 编写build.xml文件，设置build.xml的ant库为kissy-tools/ant/lib

6. 编写你的模块代码，然后build试试, 或者看完后面的内容再做第6部

   模块化机制

   • 静态
   • 打包方式：模块依赖自动合并，即把所有模块的依赖关系打包成一个脚本（deps.js)，并把所有模块的定义代码打包成另外一个脚本(combo.js)，模块的名称也根据包路径进行了更新；参见：build.xml
   • 脚本输出的方式，deps.js和combo.js都要被加载，或者间接被加载；参见：使用模块依赖自动合并的demo
   • 适用场景：这比较适合模块少且比较稳定的页面
   • 优点：能够利用缓存
   • 动态
   • 打包方式：模块依赖自动抽取，即把所有模块的依赖关系打包成一个脚本（deps.js），模块的名称重新根据包路径进行了更新；参见：build.xml
   • 模块脚本引用的方式：引入模块的依赖关系deps.js,同时动态地combo所use那些所需的模块；参见：使用模块依赖自动抽取的demo
   • 适用场景：模块多且经常变化的页面，动态地combo所use的哪些模块。
   • 优点：能实际情况加载所需的模块脚本，减少冗余代码的执行，提高页面性能。

     实际案例分析：

   • 店铺模块加载方式
   • 页面情况分析：店铺页面上的模块可被添加、删除，故每个卖家的店铺页面上的模块个数是变化的，但是目前店铺的官方模块个数还不是很多；同时店铺的模块要在集市宝贝详情页，天猫宝贝详情页，评价等页面上加载和使用，而这些二方页面上的模块个数又更少了。
   • 模块加载方式分析：个数不稳定，刚开始想用动态加载的方式；但是因为模块个数不多，又想利用浏览器缓存（店铺、宝贝详情页访问量都比较大），所以又在考虑静态加载的方式；静态加载方式的打包方式不太合适为多个业务方打多个不同的包，并且模块的代码都加载到页面上也不一定都需要得到执行。
   • 模块加载最终方案：结合静态和动态两种方式；打包方式选用属于静态的模块依赖自动抽取的方式；模块的脚本引用时，是use了所有的模块(模块combo后的js url可以被缓存住了)，但是模块的脚本真正执行是要new之后，这时就根据模块本身的class选择器是否存在来判断是否new这个模块，做到了按需new
   • 参考：旺铺浏览初始化脚本
   • 集市detail,
   • 页面情况分析：因为页面上除了sku区域的信息外，还有宝贝详情等几个tab, 这些模块都是稳定的；再有就是旺铺装修后添加的模块了，个数是变化的，但又不多；
   • 模块加载方式分析：旺铺装修后添加的模块，对detail来说可以看做是一个旺铺模块，交给旺铺来处理；这样对于detail来说，页面上的模块个数偏少，且个数稳定不变
   • 模块加载最终方案：使用静态的模块引入方式，并且结合kissy pie使用[todo： 让渐飞再补充的详细点]；
   • 参考：集市宝贝详情页静态combo脚本

     add和use的使用注意

   • 当add模块的时候，fn不会被执行，只有在use时，才会执行，并且use的执行是异步的

   // 写法一, 说明模块只有在use时，才会执行，并且use的执行是异步的
   var x=0;
   KISSY.add('x',function(){x=1})
   alert(x); // =>0 
   KISSY.use('x',function(){});
   alert(x); //=>0
   
   // 写法二，比较写法一，建议使用二的写法去获取对象
   KISSY.add('x',function(){return 1})
   KISSY.use('x',function(S,x){alert(x);});

   • combo的两种方式：

    // 方式一
   <script src="http://a.tbcdn.cn/s/kissy/1.3.0/seed.js" data-config="{combine:true}"></script>
   
   // 方式二
   KISSY.config({
      packages: [
         {
              name: "my", //包名
              tag: "20110323",//时间戳, 添加在动态脚本路径后面, 用于更新包内模块代码
              path: "./assets/module_package/", //包对应路径, 相对路径指相对于当前页面路径
              charset: "gbk" //包里模块文件编码格式
        }
    ]
   });

   • 把需要use模块，一起use, 减少http请求数

   
   var mods = [a,b,c];
   
   // 不建议这样use, 这样会产生三个http请求
   KISSY.use(mods[0], function(S,A){alert("mod a");});
   KISSY.use(mods[1], function(S,B){alert("mod b");});
   KISSY.use(mods[2], function(S,B){alert("mod c");});
   
   // 建议这样use，这样只会产生一个http请求， 前提是使用了combo的模块js加载方式
   KISSY.use(mods, function(S,A,B,C){alert("mods: a,b,c");});

   kissy 组件的使用注意

   组件调用方式的改变

   • 初始化方式： 升级后新增了直接new 的方式
   • 组件初始化的参数： 升级前会有container和config，而升级后，container作为了config的一部分

   // 如懒加载组件
   // 升级前
   KISSY.DataLazyload (container, config);
   
   // 升级后，写法一
   KISSY.DataLazyload (config);
   // 升级后，写法二
   new DataLazyload (config);

   懒加载组件

   • container: 现在container虽然兼容以前的写法，类型支持HTMLElement，但是升级后，kissy建议container只包含一个element；另外：如果container的范围比较大时就改为document或body吧，以减少懒加载范围的检查，因为kissy对非document或body的container, 会检查当前懒加载对象是否处于两个加载范围中的其中一个，他们分别是windowRegion和containerRegion

    /**
      * lazyload images
      * @private
      */
     '_loadImgs': function (windowRegion, containerRegion) {
         var self = this;
         self._images = S.filter(self._images, function (img) {
             if (elementInViewport(img, windowRegion, containerRegion)) {
                 return loadImgSrc(img);
             } else {
                 return true;
             }
         }, self);
     },

   • diff 以前只是一个数值，现在是一个对象，有四个方向的值
   • placeholder：需要有值，就用kissy默认的值吧，否则会因为src没有，影响图片懒加载的性能

     overlay组件

  // 升级前
  S.Popup('#shop-rank-popup', {
      trigger:'#shop-rank',
      align:  {
           node:  'trigger',
           points:['bc', 'tl'],
           offset:[-20, 10]
      }
  });

  // 升级后
  // 一定要添加如下的样式，否则popup对象可能不会出现
  <style>
  .ks-overlay {
        position:absolute;
        left:-9999px;
         top:-9999px;
  }
 </style>

  new Overlay.Popup({
      srcNode: '#shop-rank-popup',   // 以前的container
      trigger: '#shop-rank',
      triggerType: 'mouse',    //默认的triggerType由mouse变成了click, 在1.3下需要重新赋值一下
      align: {
         node: '#shop-rank',
         points: ['bc', 'tl'],
         offset: [-20, 10]
      }
   });   

tabs组件

  // 升级前
   var tabs = new S.Tabs(DOM.get('div.rank-tab', v), tabs_cfg);
    Event.on(tabs,'switch', function(ev){};

  // 升级后
  var tabs = new Switchable.Tabs(DOM.get('div.rank-tab', self._mod), tabs_cfg);
  tabs.on('switch', function(ev){})

兼容

根据情况做好升级兼容

• 如果联系相关业务方，大家如果能一起升级的话并且一起发布的话，最好
• 如果做不到一起升级或者一起发布的话，则需要对自己的代码做好兼容，同时还需要相关业务方协助回归相应的功能。

• 相关兼容的写法：

  • kissy.app ：kissy.app一般会使app具有add和 namespace方法

  // 使用 app namespace的兼容写法，参考http://a.tbcdn.cn/??p/global/1.0/global.js
  var TB = window['TB'] || {};
  TB.namespace = TB.namespace || function() {
     KISSY.namespace.apply(TB, arguments);
  };
  // 使用app add的兼容写法，参考：http://assets.daily.taobao.net/p/mall/base/global-v2.js
  var TB = KISSY.app ? KISSY.app('TB') : KISSY;

  性能测试

  进行必要的页面性能测试，特别要关注ie6、7下的页面性能

• 需明确：1.3较1.1.6, 有的地方支持的功能更多了，还有检测的点也更多了，可能会带来下降，有时是不可避免的；
• 可能原因: 是升级前业务逻辑本身存在可优化的地方，也有可能是kissy本身的问题
• kissy中可能会引起性能下降的地方：
  • DOM.query接口在ie6\7下，1.3的性能较1.1.6还是有明显的下降的, chrome下可能会有上升
  • 1.1.6 下性能测试
  • 1.3 下 性能测试
  • switchable 和 overlay组件
  • 提供了更多的功能，当使用较多时，会比较耗性能

• 应对的办法

  • 优化业务代码中的查询逻辑，减少查询范围和查询次数
  • 对于一个比较耗时的一个连续任务，店铺这边使用将任务分成子任务，用setTimeout来分批运行

  // 模拟循环，用setTimeout 拆分连续执行的任务
  function eachElem() {
    S.later(function () {
       if (widgetElems.length !== 0) {
           initEachWidget(widgetElems.shift());
           eachElem();
       }
    }, 0);
  }

[maxbbn]

评价的前端文龙：

因为之前就一直在用Kissy 1.2了 所以对我来说，冲击不是很大， 最有有的，我觉得还是AutoCombo这个功能，结合工具，就可以节省很多处理依赖（特别是Kissy内部模块）的工作

[shuier]

Detail KISSY 升级项目部分经验介绍 KISSY API/组件 的重大变化 模块加载方面与 KISSY 1.2 不同的是，传入 S.add 方法的回调函数，在相应模块被 use 的时候才会执行（1.2中会在 add 的时候立即执行）。如果是从1.2升级过来，需要处理好相应的顺序。 DOM.html 方法不再过多兼容不严整的 html 片断字符串参数，直接抛错。若确实需要使用不严整的 html 片断，需要先交由浏览器自身「规范化」一遍。 Datalazyload 实例支持 pause/resume 方法，用于暂停与恢复懒加载判断，灵活使用的话理论上可以显著减少页面 scroll 时的性能开销。 ImageZoom 不再自行判断大图的尺寸，需要调用者手工在大图 load事件中检测。 Switchables 组件不再兼容之前的参数，需要指定 markup 的形式种类。 脚本压缩打包 结合实际业务需求，Detail 由升级前的「合并combo与手工压缩」方案改为 KISSY Pie 自动打包。具体使用方法请参阅 KISSY Pie 的文档

升级带来的好处 DOM/Event 性能上的提升。例如，只引入seed后，只要业务模块 require 对了相应的库模块，KISSY 会区分对待浏览器，只加载当前浏览器需要的内部模块，避免无谓的计算时间损耗。 组件灵活的大大增强，如 Switchables/Overlay，可实现更复杂的交互功能。 一个槽点 严格来说这个槽点似乎应该算在 KISSY Pie 上，而且也跟 Detail 自己的开发流程有关。在 KISSY Pie 中目录的结构是 1.0 这样的形式，最终发布到线上应用的版本是 20130308 这样的形式。这种打包形式对多项目并行，同时需要做线上 beta 的发布需求来说，略显繁琐，因为一个开发版本下的更改要频繁同步到另一个开发版本。

[shuier]

tmall 商城升级（by 大遒）

总结:除了官方说明之外 使用了app?，快速兼容办法 window.MFP = (KISSY.app && KISSY.app(“MFP”)) || KISSY datalazy新加pause和resume方法，适时停止lazy提升性能，比如在scrolling过程中或变为隐藏时 overlay除了方法变了，html结构也变了，样式要重写 waterfall，config.effect如果1.1.6中使用了show, 1.3中可以调为””,达到同样效果