Backbone + ES2015 Class

在 ES2015 下使用 Backbone,需要一点点小技巧。

小型项目还是 Backbone 用起来比较舒心,所以写着写着又开始用它了。这次还用到 ES2015 和 Babel,于是疑问就来了:怎么在 ES2015 下使用 Backbone 呢?

普通用法

Backbone 自带 .extend() 方法,在早期的蛮荒岁月可以帮我们方便的创建各种子类。

var MyView = Backbone.View.extend({
  events: {

  },
  tagName: 'div',
  initialize: function () {

  }
});

以前这样确实很方便,代码也很好读。但是 ES2015 引入了新的 Class 规范,写出来是这样婶儿的:

class MyView extends Backbone.View {
  // 其实不能这样写
  tagName: 'div'
  events: {

  }
  // 上面这样写是不对的
  constructor() {

  }
}

这个时候问题来了。ES2015 不支持直接声明类属性,也就是上面代码中的 tagNameevents,是不能这样写的。因为它实际上只是重新包装了原型继承那一套东西,所以上面的代码实际上等效于:

MyView = function () {

}
MyView.prototype = new Backbone.View();
MyView.prototype.tagName = 'div';
MyView.prototype.events = {

};

这样的结果,不同实例间实际在共享方法和属性,包括 tagNameevents。如果是简单对象,比如字符串和数字,用 = 赋值还好;如果是复杂对象,比如数组,就很容易出问题。

Backbone 1.0 之前也会有这个问题,但是忘记从哪个版本开始就修复了。

新的用法

想要在 ES2015 中继续 Backbone 当然也是可以的。目前看来有三种方式:

  1. 把属性转化为方法。Backbone 对属性的处理都是委托给 _.result(),所以属性和方法的效果是一样的。
  2. 继续使用 MyClass.prototype.someProp = 'value';
  3. 将初始化对象放在构造函数中。

我个人比较喜欢第三种方法,因为它更接近之前的写法,而且结合 Babel、Webpack 等编译打包工具,也可以做到私有。

class MyView extends Backbone.View {
  constructor(init) {
    super(_.extend(init, {
      events: {

      },
      tageName: 'div'
    });
  }
}

未来,ES2016

ES2016 中引入了很重要的 Decorators 概念,顾名思义,它会显式的告诉运行时下面是些什么东西,那么运行时自然也就可以按照对应的规则去处理。

@props({
  tagName: 'div',
  events: {

  }
})
class MyView extends Backbone.View {
  constructor(init) {
    super(init);
  }
}

参考文章

本篇内容主要参考自以下两篇:

使用Backbone的正确姿势

2012年来到点乐之后,我开始大规模开发Web单页应用。期间Backbone一直是我的主力框架,不过直到最近我才明白使用Backbone的正确姿势是什么。希望本文能让后来者少走些弯路。

2012年来到点乐之后,我开始投身Web应用开发。当时我选择Backbone作为主力框架,刚开始做难免会带着各种旧习惯,只有一边使用一边摸索。最近我终于搞明白使用Backbone的正确姿势,记叙于此,希望能让后来者少走些弯路。

使用框架时,我的原则是:既然使用了这个框架,就应该按照这个框架的思路解决问题,一定要把它的功能都用上,要按照它的方式组织代码,这样才对得起学习使用的成本。所以下面的“正确姿势”,自然也是奔着全面使用Backbone的内建功能、尽量符合Backbone的设计思路,这样的目的总结的。

本文假定读者熟悉JavaScript,对Backbone有一定程度的了解。

View

我比较同意《JavaScript设计模式》中的观点,Backbone的设计很难讲是更接近MVP还是更接近MVC,而是在Web前端这个大环境下,基于其技术特点,吸取各种设计模式的优点做出最合适的的实现。Web应用中,视图的实现自然应该交给HTML和CSS负责,而在数据变化时更新视图,以及响应用户操作的事情,就交给Backbone.View

Backbone.View提供非常直观的events帮助我们注册事件,免受使用jQuery的.on.on.on之苦。事件被委托给$el,不仅节省资源,并且做列表类应用需要操作多个子节点时,无需再绑定事件。

不过请注意,这里的事件委托仍然有赖冒泡机制,所以诸如loaderror等不冒泡的事件无法委托给$el处理(submit在早期IE下也不行,但是jQuery会代发冒泡版),只能手工侦听具体节点。另外,Backbone会把处理函数代理给View的实例,所以函数中的this指向是实例,而不再是触发事件的DOM元素。

列表的前世今生

接着,来点代码,看看最常用的UI范式——列表。Backbone中,搭配使用Backbone.CollectionBackbone.View可以方便的实现列表类组件,不过因为Backbone本身的限制很少,实现方法很多。早期我习惯于通过reset方法和reset事件来操作列表,后来慢慢体会到,接下来的做法更合适。

HTML部分:

    // 这里假设我们要做一个todo列表
    <ul>
      <script type="text/x-handlebars-template">
      <li id="{{id}}">
        <input type="checkbox" name="todo" value="{{id}}">
        {{title}} <time datetime="{{create_time}}">{{create_time}}</time>
      </li>
      </script>
    </ul>

JavaScript部分(使用Handlebars作为模板引擎):

    var ListView = Backbone.View.extend({
      fragment: '',
      events: {

      },
      initialize: function () {
        this.template = Handlebars.compile(this.$('script').remove().html().replace(/r|n|s{2,}/g, '');

        this.collection.on('add', this.collection_addHandler, this);
        this.collection.on('remove', this.collection_removeHandler, this);
        this.collection.on('sync', this.collection_syncHandler, this);
        this.collection.fetch();
      },
      collection_addHandler: function (model) {
        this.fragment += this.template(model.toJSON());
      },
      collection_removeHandler: function (model) {
        this.$('#' + model.id).remove();
      },
      collection_syncHandler: function () {
        if (this.fragment) {
          this.$el.append(this.fragment);
          this.fragment = '';
        }
      }
    });

之所以建议这么做,因为Backbone.Collection有三个特点:

  1. model的事件会由collection向外转播(相当于冒泡)
  2. 取得数据后,collection会逐个创建model,每次都会广播add事件
  3. .fetch().set()时,新数据中不曾出现的对象(以id为标识)会被移除

列表中还有一些技巧,将在后文呈现。

钦差大臣options

早先取数据时为了向服务器传递变量,或者使用特定的jQuery参数,我经常覆写.sync()方法,甚至直接使用$.ajax()。后来发现,各函数的options(除去少数几个return之外)都会传递到下一个函数,直至最后;期间每一步的参数都会合并进来向后传递。

所以我们只需要在第一次调用函数时,将需要的值放在options里即可 。比如,要保存model里的数据,API服务器和当前服务器不在同域,就可以这样:

// 关于xhrFields,可以参考jQuery文档:http://api.jquery.com/jQuery.ajax/
model.save(null, {
  xhrFields: {
    withCredentials: true
  }
});

其实,options是个很巧妙的设计。Backbone作为框架,必须给其它库和业务逻辑留出足够的空间,使用options,随便其他开发者传什么值,最后都能传回业务逻辑中。另外,当参数个数比较多的时候,使用options也有助于阅读代码。

options进阶

基于“从头传到尾”这个性质,我们还可以发明一些特殊用法。比如上一节的例子,我希望给每个元素增加一个删除按钮,点击后移除元素。重点是:以渐隐动画来表现移除动作。在Backbone中,.destroy()方法会通知服务器删除对象(.remove()方法只是从当前集合中移除model,无法满足需要),并且触发destroy事件,我们可以在这里插入动画;但立刻就又会触发remove事件,所以只是在collection_destroyHandler的时候fadeOut是不够的,还要防止collection_removeHandler在动画结束前直接移除dom。

这个时候,我们就可以利用optionsdestroy()支持参数{wait: true},可以等待服务器返回成功后才移除model。于是我们就能确保对象已经从服务器上清除后,再以视图体现;同时,只要检查options里是否包含这个属性,就可以知道当前触发collection_removeHandler的是.destroy()还是.remove(),再决定是否立刻移除节点就很容易了。(其实随便传个什么标记都可以,这里使用{wait: true}可以获得更好的体验。)

    // 一致的代码我就不写了
    events: {
      'click .delele-button': 'deleteButton_clickHandler'
    },
    initialize: function () {
      // 一致的代码
      // ....
      // 不再重写
      this.collection.on('destroy', this.collection_destroyHandler, this);
    },
    collection_destroyHandler: function (model) {
      this.$('#' + model.id).fadeOut(function () { $(this).remove(); });
    },
    collection_removeHandler: function (model, collection, options) {
      if (!options.wait) { // 没有wait
        this.$('#' + model.id).remove();
      }
    },
    deleteButton_clickHandler: function (event) {
      var id = $(event.target).closest('li').attr('id');
      this.collection.get(id).destroy({wait: true}); // 服务器返回确认才真正移除
    }

利用options能达成的效果还有很多。比如,有些时候我们想往model里放一些特殊用途的数据,只在渲染时候用,不保存到服务器上。通过研究源码我们发现,同样调用.toJSON().save()会传入含有各种参数的options,而手动调用则不会。于是我们又能根据options里的属性返回不同的数据,满足不同的需要。

这些实现本文不再一一详述,大家请自行琢磨,欢迎留言探讨。

和服务器步调一致—— sync & fetch

有些习惯延续自之前的项目,比如请求远程数据。早期我总想用$.ajax从服务器端把数据取来,然后再resetcollection或者model。直到最近开发新项目:tiger-prawn + lemon-grass(也即点乐后台V5),我开始开发RESTful的后端,配合专为RESTful设计的Backbone,贯彻“同步”思路,于是我终于醒悟,发出文章开头那句感慨——我终于明白使用Backbone的正确姿势了。

“同步”是Backbone非常重要的设计思路,也是用户体验里非常重要的一环。我们经常要面对多端的环境,尤其是开发企业级应用,多人协作办公,必须保证数据在每个终端看起来一致。我一开始很难理解为什么.fetch()回来数据后,除非指定{remove: false},否则新数据中不再存在的对象会被移出collection。这个疑问后来在开发集体协作的todo列表时得到解答。

还拿前文的todo列表做例子。想象列表面向一个工作组,组内成员均从列表当中接受工作,完成后勾上checkbox表示结案;别的地方还会有需求源源不断的塞入这个列表中。这个时候,数据同步就显得尤为重要。某甲勾掉一条任务,需要从其他人的列表中勾掉同一条任务。由于我们数据交互的主要手段仍然是Ajax,服务器无法向浏览器发出指令,只能由浏览器通过返回值进行操作,所以,将“同步”作为强制性要求,本地collection根据返回值的变化,该修改的修改,该移除的移除,就是最佳选择了。

trigger: false未必都有用

最后再说个小问题。有时候我希望改变路径,但不要刷新页面,比如创建文章/article/create/,.save()后得到文章id,跳转到/article/id。因为仍然处于编辑状态,所以不需要刷新页面。一开始我以为router.navigate(‘#/article/id’, {trigger: false});,加个参数{trigger: false}`就可以防止路由生效,后来发现不行。

出于种种原因,比如服务器没做重定向,我一直没用pushState。此种状态下,Backbone使用setInterval检查地址栏变化,所以只要地址栏有修改,就会触发相应的路由。

相关项目

下面是我做过并且在维护的一些使用了Backbone的项目。这些项目未必都做到了以上几点,所以仅供参考。

团队培训项目团队培训项目二期,其实从这两个项目中就能看出我思路的变化。

游戏宝典 手机应用,虽然项目停摆了……找时间更新移植到phonegap上。

总结

Backbone是一个轻量级,入侵程度很低的框架。可以很方便的结合各种其他库来使用,对使用者的要求也很少,易于学习。不过如果能以正确的姿势操作,又能达到事半功倍的效果。这篇文章写得很费劲,有些东西总是感觉话到嘴边写不出来,反复修改多次对最后两段仍不满意。哎,以后再说吧,先发了。

Nervenet + Backbone

使用Backbone时,配合Nervenet能取得很好的效果。

介绍Nervenet起源时我提到,Nervenet一名很大程度上来自于Backbone。使用Backbone进行开发期间,我体会到很多方便之处,也发现仍有不少障碍横垣在前,于是总结之前的经验,取Robotlegs之长,做出了这个框架。当然,Nervenet并非专门针对Backbone开发,自然也不会依赖它,不过由于设计初衷和后期实现,结合Nervenet使用Backbone时着实有一些优势。

context.createInstance创建实例

我们知道,依赖注入的对象一般都是类的实例;类实例化时,可能会用到一些尚未注入的属性,所以通常需要在注入后调用实例的postConstruct方法,才能彻底完成构造。Backbone为了实现其独特的架构,将真正的构造函数construct隐藏了起来,开发者操作的initialize函数实际上是初始化函数,从执行顺序来讲与上文中的postConstruct基本一致。同时,Backbone的几大基础类都接受传入初始化对象,即new Backbone.View(options);中的optionsoptions中若包含elmodel等属性,将直接用来填充类自身的属性,甚至从页面当中找到dom结构操作。

若采用普通的依赖注入,则需要在每个类中再实现一个postConstruct方法,增加维护成本和迁移成本。使用Nervenet提供的context.createInstance方法,可以在实例化对象时,扫描参数对象,完成注入,只需要保留initialize函数,非常简单,而且可以直接沿用之前的代码。

var view = context.createIntance(Backbone.View, {
  model: '{{$model}}'
});

从代码可以看出,要完成上述功能,还必须实现一个特性:“注入指定类型的对象”。Javascript是弱类型语言,代码中不包含对象类型,所以之前的类库只能根据“属性名”注入。对于Backbone来说,modelcollection这些都是特有的关键字,要注入的也多是它们,而要注入model,就必须先map一个值到model这个key中——这意味着同一组map只能给单一Backbone.View对象注入依赖,在实际开发难以想象。Nervenet的优势在于可以由“属性值”指定注入的内容,这样不同的View,可以指定不同的model,问题迎刃而解。

// 给不同的view注入不同的model
context.createInstance(Backbone.View, {
  model: '{{$user-model}}'
});

context.createInstance(Backbone.View, {
  model: '{{$job-model}}'
});

infuse.js的解决方案是“子注入器”,通过创建子注入器,构造不同的map,就可以对不同对象注入不同的值了)

mediatorMap管理mediator

了解Backbone的人都知道,虽然名为View,但其实Backbone.View更接近一般意义上的Mediator,而通常意义上的View则由HTML+CSS负责实现。我通常使用Backbone.View开发组件,组件拼接起来就是完整功能的页面嘛。所以我就设计了一个功能来帮助我管理mediator,就是context.mediatorMap,它主要提供三个方法:

.map(selector, MediatorClass[, options]),通常和.check(dom)连用。前者将选择器和类关联,后者则检查某个DOM节点下是否有符合选择器的节点,并为它们自动创建mediator

// 先这么注册一下
context.mediatorMap.map('.checkbox', MyCheckbox, options);

// 然后就可以用了
context.mediatorMap.check(document.getElementById('my-form'));

.createMediator(dom, MediatorClass[, args]),直接为某DOM节点创建mediator

// 直接为DOM创建mediator
context.mediatorMap.createMediator(document.body, MyGUI);

创建mediator的过程基本相同,自动注入依赖,并把目标DOM节点会作为第一个参数,或者第一个参数对象的el属性传给mediator的构造函数——后者当然是为了兼容Backbone。

Backbone基于jQuery,所以操作一个DOM和操作一组DOM对它来说没有什么区别,留意到这点后,我在Nervenet中也作相应照顾,可以通过options设置isSingle=true;表示使用者希望使用一个实例来管理所有符合要求的节点。默认false,会针对每个DOM节点创建独立的mediator

可惜的是,HTML没有提供方便的手段获取DOM节点的变化,所以暂时只好使用手工检查了;另外,querySelectorAll这个方法也存在一定的兼容性问题,所以,目前mediatorMap仍然只是0.1.2版的测试功能,以后可能会有各种改动。

前端框架点评

点评一下当下各种前端框架、类库。

前两天被人@,提问前端框架的问题。这还是第一次在微博上被陌生人提问,感觉有点小激动。今天写篇小文章,简单点评一下我用过的前端框架,希望对大家有所帮助。

本文涉及的范围

本文要点评的前端框架,都是我用过的,以JavaScript框架为主,也可能包括一些工具类库。由于前端的特殊性,弱语言HTML和CSS是必不可少的工具,运行机制导致很多成熟的工程学方法没法用,必须用工具库补充。烦请大家不要抠字眼,我一向很马虎,呵呵。

Bootstrap

一定要先推荐Bootstrap。它由Twitter的两位工程师首创,当前版本2.3.1,涵盖了文本、布局、表单、工具,除了暂时没有日期选择器之外,几乎包含了网页所需的一切。我们知道,网页出现是为了传递信息,而成熟的印刷业对其影响很大,表现出来就是,HTML中很多标签,比如H1~H6p等,都是有具体语义的。但很多前端框架并未给予他们足够的重视,所以往往需要我们重置或者自己动手写。Bootstrap则不是这样。它不仅包含大量组件,还帮助我们给每种可能用到的语义标签都定义了样式,又设计出很多helper;而其网格系统也能帮我们出色完成排版工作。总而言之,使用它几乎足以满足任何网页开发需求。

值得一提的是,Bootstrap的组件和Widget都基于HTML标签构建,非常好用;而响应用户操作则基于对document的侦听,所以几乎不会对我们其它代码逻辑造成影响,我们可以放心大胆的在项目当中使用。当然,Bootstrap依赖jQuery,后者近期遭遇到一些纷争。不过我还是要强烈推荐这个框架。

jQuery UI

比较遗憾的是,虽然号称UI,但jQuery UI只能算作一个组件库。因为缺少基础排版支持,所以既想使用jQuery UI,又想和自己的样式保持一致会有些困难,需要花费不少时间做修改。

抛开这一点,jQuery UI也是个很好的工具,几个widget都很实用,文档丰富详实,如果项目本身对交互要求不高,只是个别地方需要一些功能补充,jQuery UI确实是不错的选择。尤其当我们需要draggablesortableresizable这几个功能时,选择的余地真的不大。

HTML5 Boilerplate

这个工具力图给开发者提供一个舒适的起点。他们为项目建立了标准化的目录结构,并且把常用的资源都整理在合适的位置,这样我们只需要替换它们就能保证项目对所有浏览器都有完美表现。同时,他们重置了CSS,引入了GA统计,在页面中标记了合适的输入点,这样我们能尽快投入到项目逻辑的开发中。

但这个工具的问题也很明显,它努力达成的目标,是消弭浏览期差异。假如我们只需要统一的环境就能开展工作,那H5B就足够了;而实际上,我们通常需要更多,比如排版、比如组件。所以,这个工具对我来说,学习的意义大于使用的意义。

HTML KickStart

我见过的前端框架里只有这个跟Bootstrap的覆盖面接近。它的设计更好,更鲜艳更有活力,不过最近的开发好像慢了下来。我并没有真正使用它,因为它的组件太少了。

Backbone

非常好的MV*框架,真的像根脊柱一样,把被jQuery拆的七零八散的js统一在合理的框架内,让整个项目都变得协调了。引入Collection真的很天才,结合其出色的View设计——其实Backbone的View并不是传统意义上的View,更像mediator——可以看出,Backbone的设计者对Web开发有着深刻理解。哦,差点忘了,Router还能帮我们很好的整理单页应用的逻辑。

不过js毕竟是一门很烂的语言——或者让我换种表述方式,缺陷很多,所以它尚无法做到像AS3的Robotlegs那样好。不过,如果我们希望把代码组织的更好,Backbone类的框架是不可或缺的。

Rachet

Rachet的目的和架构,很像Bootstrap,不过它瞄准在移动端。Rachet现在仍处于比较低级的阶段,组件太少,开发起来不太方便,最多相当于Kickstart把。可惜的是,移动端移动框架普遍较弱,在我看来,基于它的Junior仍然是不二之选。

Zepto

说到移动端开发就不能不提Zepto。它力图实现一个十分类似jQuery的库,不过只考虑支持移动端,所以体积会小很多,速度也会快不少。Zepto的升级频率最近也不高,不过还是到了1.0。新版Zepto放弃了ruby,使用coffee作为编译工具,支持使用者自由组合功能模块,相当贴心。

不过具体使用时,还是会有一些函数的用法和jQuery不同,需要注意。举个例子,css函数,jQuery里支持数字,比如$('div').css('height', 100),会把页面中所有div的高度设置为100px;而Zepto不行,必须$('div').css('height', '100px')才会正常工作。

jQuery Mobile

强大的jQuery团队最失败的作品。贪恋于风光的过去,迷信“全覆盖”,使得jQuery Mobile步履蹒跚,在移动平台上无法取得足够好的性能表现(早期版本甚至不支持固定底部)。而这直接带来了对HTML在移动端的质疑。有很多本不擅长前端开发的人,看到Phonegap,就直接上jQuery Mobile,结果发现性能不行,体验很差,便在各种渠道大放厥词,说HTML不行。这种行为直接伤害了HTML和Hybrid应用。

jQuery Mobile失败不仅在于此。jQuery本身方便快捷,使用它很容易养成不重视代码组织的习惯;而在移动端,单页应用占据主流,这意味着,使用jQuery Mobile很可能无法良好的组织代码,直接带来项目维护成本的提高。另外,早期版本的设计也不可避免的带有大量Web痕迹,导致实用性不足。所以直到今天,jQuery Mobile都还是个悲剧。

不过,jQuery 2.0已经beta2了,我们知道,jQuery 2.0里放弃了对IE678的支持,性能会得到不小的提升;jQuery Mobile 1.3已经引入了对hash的支持,组织代码好多了;同时,随着3次小版本更新,越来越多适用于移动应用的组件加入进来,大大扩充了军备库。我认为,未来的jQuery Mobile,值得一试。

Sencha Touch

大家可能还记得,Facebook闹过一阵,说HTML5不够好,还把他们的手机客户端用原生重做了一遍。之后Sencha的两位工程师表示不服,以HTML5为基础开发了功能几乎完全一样的客户端,他们用到的框架就是Sencha Touch。据说,它的性能比jQuery Mobile好不少。

但是,真正用了就知道,sencha touch实在太不“前端”了。它里面几乎没有给HTML和CSS留下太多位置,明明十分强力的布局样式工具,被封装成了单薄的接口;但是没少往JS框架里加内容。结果就是用起来非常复杂,随时需要看文档;自定义困难,它里面甚至有一个属性叫“html”,用来填入大段文本类型的html;数级嵌套起来的对象也很让人头疼,而且感觉维护也不会太容易。所以我做了一半就还是放弃了。劝大家也别去尝试了。

如果有哪位高人愿意以实际经验教育我的,我洗耳恭听。

诡异BUG之:IE下表单必须提交两次

未妥善解决,有待进一步研究,求指导。

做前端遇鬼是常事儿,比如今天,就遇到个:

  1. IE6~10
  2. jQuery 1.8.3
  3. Backbone 0.9.2
  4. HTML5头
  5. 一个Backbone.View,内部有一个formView托管formsubmit事件,根据classaction进行不同的操作,或者验证数据提交表单
  6. 第一次提交,验证通过,return true,没反应
  7. 第二次提交,验证通过,return true,表单提交
  8. 其它浏览器表现正常

提炼这些Bug描述就花了不少时间,反复Google也没有什么结果。比如,StackOverflow上类似问题的解答是:submit原本不会冒泡,所以应该直接侦听form;但实际上jQuery1.4之后已经支持submit事件的托管了,我的实验也支持这个结果。

至于导致问题的原因,我还没想明白也没测出来,留着以后再做吧。最后用Hack的方式暂时解决:

if ($.browser.msie && isIEFirstSubmit) {
  isIEFirstSubmit = false;
  setTimeout(function () {
    form.submit();
  }, 50);
}

有了解这个的高人还请不吝赐教。有感兴趣的同学可以去试试:http://www.dianjoy.com/dev/#/user/updateuser

使用免费CDN加速JavaScript的加载

妥善利用互联网上的免费CDN资源,加速项目中JavaScript的加载。

做前端的,基本都会用上各种开源的框架、类库。在项目中引用它们,就可能需要把用到的文件纳入版本库,这样每次类库更新,我们也得跟着更新文件,比较麻烦。而且,我们知道,浏览器对同一个域名下的资源同时加载的数量是有限制的,加载页面时光类库的CSS和JS就得搞半天,整体速度也会被拖累。

好在很多仁人志士已经提供免费的CDN分流服务,帮助我们托管类库。我用到的主要有这些:

jQuery

jQuery流行度毋庸置疑,所以微软和Google都提供了jQuery系列,包括UI和Mobile的CDN,Google的CDN还包括一些其它类库,比如prototype和Mootools等。

微软:http://www.asp.net/ajaxlibrary/cdn.ashx#jQuery_Releases_on_the_CDN_0

Google:https://developers.google.com/speed/libraries/devguide

Bootstrap

Bootstrap是由来自twitter的两名“Nerd”工程师创建的前端框架,非常棒,刚好覆盖了网站页面所需,组合使用无往不利。BootstrapCDN为我们提供了相应的服务:

http://www.bootstrapcdn.com/

Underscore和Backbone

cdnjs.com 这种业界良心提供了最丰富的CDN资源,还包括了每种类库的官网或者其在github上的链接(好吧,很多时候他们就是一回事儿),我觉得甚至可以把这个站点当成学习的出发点。肉大师项目中用到的Underscore和Backbone就取自这里,感谢他们。

值得一提的是他们的域名也很好记~

书评:《基于MVC的JavaScript Web富应用开发》

这本书适用人群应该是中级偏下的开发者,通过阅读这本书能够梳理一下当下比较流行的HTML5+CSS3+JavaScript知识,能够学习到MVC入门知识,可以开始用MVC模式来操作具体应用。

封面
基于MVC的JavaScript Web富应用开发一书的封面

知道这本书源于那篇博客:《旅行,写作,编程》。读完文章后,我忍不住顿足捶胸,尼玛这才是生活啊,这才是程序员应有的生活啊!!最尼玛让人崩溃的是,作者才21啊!!就把我30岁之后的梦想实现了。感叹之后,屌丝的生活还得继续。谁让咱们一出生就是Hard模式呢,老实说我对目前的生活还算基本满意,当然如果我也能环游世界写本书啥的,我可能也觉得洒家这辈子值了。

继续阅读“书评:《基于MVC的JavaScript Web富应用开发》”

Backbone.js笔记

关于Backbone的笔记。

关于事件

  • 使用Backbone里,我们可以继承Backbone.View,并且侦听UI事件。这些操作是通过jQuery或者Zepto的事件委托实现的,所以很重要的一点就是:这些事件都是UI事件,loaderror这些事件是无法在events属性里注册并被侦听到的。
  • 因为是托管的事件,事件处理函数最好用event.currentTarget来寻到节点
  • model的事件都会被collection转发,所以可以直接侦听collection;同理,除非remove并等待垃圾回收的model,也不应简单的调用off(),因为这会使collection没法侦听到事件,漏掉一些处理。

路由解析规则

这点文档中说得不算太详尽,我摸索如下:

  1. 路径分析以#/为起始,所以链接应该如#/app/add
  2. /是很重要的分隔符,末尾的/会被认为有下一级参数,比如app/list/的规则就不适用于http://domain.com/#/app/list这样的路径
  3. 规则只匹配一次,不会多次执行
  4. 刷新页面的方法:
    Backbone.history.loadUrl(Backbone.history.fragment);

其它关于Backbone.js的文章

Backbone.js经验两则

重写Backbone.js的加载动作

Backbone.js经验两则

最近使用backbone遇到的两个问题,分享下。

使用HTML5,实现从桌面拖拽到网页

使用HTML5新增加的API,可以很方便的实现拖拽, 包括从桌面拖拽到网页上(部分浏览器比如Chrome还可以把东西从网页拖拽到桌面),这个操作不在今天的讨论之内,可以参考:NATIVE HTML5 DRAG AND DROP这篇文章,讲得足够详细了。

当我试图在Backbone框架上使用这个功能的时候,问题出现了。开始我没多想,直接这么写的:

var myView = Backbone.View.extend({
  events: {
    "drop img": "img_dropHandler"
  },
  img_dropHandler: function (event) {
    var reader = new FileReader();
    var img = event.target;
    reader.onload = function (event) {
      $(img).attr('src', event.target.result);
    }
    result.readAsDataURL(event.dataTransfer.files[0]);
  }
});

结果运行时提示我,event对象没有dataTransfer属性。我用的是最新版本的Chrome,理应是对HTML5支持最好的,而且文中也说代码在Firefox和Chrome下运行通过。后来检查了一下event,发现是f.Event,似乎原本应该是MouseEvent或者Event什么的。于是我把属性展开,看到了originalEvent这个属性,是MouseEvent;再展开originalEvent,就看到了dataTransfer属性,里面有期望中的所有属性。看来是Backbone并没有直接使用原始事件,而是封装了一层再广播。(更正)事件代理是通过jQuery来做的,jQuery在这里把原始事件封装了一层再进行转播,导致原始事件的属性没有完全复制。解决方法很简单,多写几个字母就行了:

// 其它地方都一样
result.readAsDataURL(event.originalEvent.dataTransfer.files[0]);

Model中数组的处理

先看一段代码:

var ModelClass = Backbone.Model.extend({
  defaults: {
    contents: []
  }
});
var model1 = new ModelClass();
var arr = model1.get('contents');
arr[0] = 'haha';
var model2 = new ModelClass();
console.log(model2.get('contents'));

大家猜猜结果是什么?竟然是“[‘haha’]”!这个我只能认为是Backbone.js的bug了。解决方法是先复制一个数组,对数据操作后再赋值回去,如下:

var model1 = new ModelClass();
var arr = model1.get('contents').concat();
arr[0] = 'haha';
model1.set('contents', arr);

重写Backbone.js的加载动作

解决覆盖Backbone.Model的parse方法无效的问题。

居然在Google里找不到类似的情况,难道只有我一个人会有这种疑问么……

我在使用Backbone的时候,遇到一个问题:我需要用 Backbone.Model 或者 Backbone.Collection 来加载一些远程数据,一般来说都是静态文件,比如HTML或者XML,既不满足RESTful,也不是JSON;虽然不很符合Backbone的要求,不过因为是静态的,所以我觉得ajax应该都没问题。当我按照这个思路写下去,一般就是这样:

var MyModelClass = Backbone.Model.extend({
  url: 'config.xml',
  parse: function (response) {
    console.log(response);
  }
});
var model = new MyModelClass();
model.fetch();

但是运行之后,我发现被覆盖的 parse 没有执行。然而查看网络,目标文件已经被正常加载。作为Backbone的初学者,也不知道问题出在哪里。不得已找来源码跟踪,发现Backbone实现 fetch 是委托给 Backbone.sync 方法,但是在实现的时候会把数据格式设置为json:

// http://documentcloud.github.com/backbone/backbone.js
// Default JSON-request options.
var params = {type: type, dataType: 'json'};

而 jQuery 1.4版之后,会对返回的数据格式进行验证,如果不符合就抛出异常。所以当我那些不是 JSON 但声明是 JSON 的数据加载完毕后,jQuery 就会抛出异常,于是覆盖的parse也就不执行了。

如果远程数据不是JSON,需要覆盖数据加载逻辑时,就应该覆写 .fetch(),比如这样:

var MyModelClass = Backbone.Model.extend({
  url: 'config.xml',
  fetch: function () {
    $.ajax({
      url: this.url,
      context: this,
      success: this.parse
    });
  }
  parse: function (response) {
    console.log(response);
  }
});

var model = new MyModelClass();
model.fecth();

我认为不应该重写 .sync(),因为实际应用中,不同的 Model 和 Collection 可能要提供加载远程数据、加载模板、与 LocalStorage 交互等不同的功能,重写sync也很难满足需要。所以不妨直接在不同的类里面覆盖各自的fetch、save方法。


这篇文章还有人看,那就更新一下。(2016-11-25)

Backbone 用的久了,发现它其实设计了更好的办法解决这种问题:调用 .fetch() 的时候传递 options

// 以下代码通过继承并覆写 .fetch() 方法,告知 jQuery 返回数据类型是 XML
var MyModel = Backbone.Model.extend({
  fetch: function (options) {
    options = options || {};
    options.dataType = 'xml';
    return Backbone.Model.prototype.fetch.call(this, options);
  },
  parse: function (response) {
    console.log(response); // jQuery 会帮我们分析这个 XML
  }
});

这种方式比上面的好得多。