使用 CoffeeScript 编写backbone.js 应用程序是否存在任何固有问题?您是否遇到了一些无法解决的问题或不得不使用一些特别笨拙的解决方法?
3 回答
没有问题,真的。至少,没有一个是不容易解决的。
使用 CS 的问题与在任何地方使用 CS 时可能遇到的问题相同:
- 调试仍然在生成的 JS 中完成
- CS 需要一个有时会很尴尬的预处理步骤
- 你团队的其他成员可能不知道 CS
- CS有一些奇怪的事情(他们引入了“类”,但它们不是真正的类)
此外,由于使用 Coffeescript 的 Backbone 开发是基于“类”的,因此您会发现自己希望将您的类分成单独的文件,在单独的文件夹中。因此,您可能会遇到类定义无序的情况。例如,您的集合可能会在您的模型之前定义,这是不可能的。为此,我建议使用可以管理依赖项(导入)的东西。我使用的是咖啡烤面包机,但还有其他几个选项(例如,Rails 在资产管道中内置了依赖项管理)
这是我编写 Backbone 代码的首选方式。在我看来,Backbone.js 开发实际上在 CoffeeScript 中比在 Javascript 中更好。对我来说,它们就像巧克力和花生酱一样。(不是每个人都喜欢巧克力/花生酱……不是每个人都喜欢 BB/CS)
类语义 Backbone 开发严重依赖于扩展原型,这是 CoffeeScript 内置的东西。因此,您将在 JS 中扩展视图的位置:
App.Models.MyModel = Backbone.View.extend({
render: function() {
...
}
});
CS 替代方案是原生体验:
class App.Models.MyModel extends Backbone.Model
render: ->
...
覆盖函数 您在 Backbone 中经常做的一些事情,比如覆盖函数变得更加简单。在 Javascript 中:
constructor: function ( attributes, options ) {
this.constructor.__super__.constructor.apply( this, arguments );
...
}
变成:
constructor: (attributes, options) ->
super
"this" 上下文绑定 CS 中的“胖箭头”在需要声明函数的上下文为“this”时非常有用
当函数被回调时,Javascript 会以不同的方式设置“this”。有几种方法可以解决它,但开箱即用,很尴尬:
initialize: function() {
this.model.bind('reset', this.render);
},
render: function () {
this.$el.html("<ul></ul>");
this.model.each(this.renderItem); // <--- Fails on "reset" because 'this' is wrong
return this;
}
CoffeeScript 有一个=>
标记,当它被任何人调用时,它会自动将“this”绑定到函数:
initialize: ->
@model.bind 'reset', @render
render: =>
@$el.html '<ul></ul>'
@model.each @renderItem # The fat arrow fixed it for you
@
总而言之,Backbone.js 代码更容易编写,并且用 CS 编写时更容易阅读。至少,这是我的看法。
祝你好运!
CoffeeScript 和 Backbone.js 都是由同一作者(Jeremy Ashkenas)编写的。默认情况下,backbone-on-rails gem 会生成 CoffeeScript。尽管某些插件(例如您提到的 Backbone-relational)可能需要额外设置,但 Backbone 本身与 CoffeeScript 配合得非常好。
CoffeeScript 只是 JavaScript 之上的一个语法层。它本质上是 JavaScript。你可以在 JavaScript 中做的任何事情都可以在 CoffeeScript 中重现。