为什么create()的参数更像setProperties()？

Question

我发现Ember的反直觉是你可以使用参数覆盖计算属性设置函数(http://emberjs.com/#toc_computed-properties-setters)create().见http://jsfiddle.net/zJQJw/2/

我发现最好的解决方法是打电话create().setProperties(properties)而不是create(properties),但这对我来说似乎是一个不必要的问题.我意识到这可能会打破一些应用程序,但你会考虑让create()行为更像setProperties()？

我要求这个的动机是在使用模式init()之前调用它.这还不是一个大问题,但我可以看到在某些情况下这是不可取的.这是一个完全人为的例子,但也许你可以看到我得到了什么？http://jsfiddle.net/QJ8vX/2/setProperties()create().setProperties(properties)

我可以看到维持当前行为的唯一原因是执行特定于实例的setter方法覆盖.但在这些情况下,你可以轻松做到MyClass.extend({ overridenMethod: ... }).create(properties)

Ember 1.0会考虑这样的变化吗？或者我对Ember的对象模型应该如何工作有错误的想法？

Answer 1

我们推迟这一变化的主要原因是它无法将基类上定义的属性覆盖为计算属性.例如,在属性中Ember.View,template属性是计算属性:

template: Ember.computed(function(key, value) {
  if (value !== undefined) { return value; }

  var templateName = get(this, 'templateName'),
      template = this.templateForName(templateName, 'template');

  return template || get(this, 'defaultTemplate');
}).property('templateName').cacheable(),

在创建子类时Ember.View,您可能希望使用显式模板函数覆盖此定义:

Ember.View.create({ template: Ember.Handlebars.compile('...') });

如果计算属性不处理setter情况,则此覆盖计算属性的尝试将是静默失败.

如果我们进行了此更改,它还会引入有关观察者是否应触发传递给create方法的属性的其他问题.两者都有可能实现,两种方法都存在强烈的争论.

在1.0的准备阶段,考虑一种方法似乎是合理的:

• 改变create使用setProperties语义
• 添加一个保留现有语义的新API(override或createWithOverride),以防您明确想要覆盖现有的计算属性
• 抑制由于create(或决定不)设置的属性的观察者
• 找到一种方法来检测和警告尝试使用create具有未实现setter的计算属性的API.

我需要更多地讨论它,并考虑对现有应用程序的影响,但它绝对值得考虑,因为它对于新开发人员来说绝对是一个非常大的问题.我们需要改变行为的事实ember-data是一个非常好的线索,表明事情并不完全正确.