为什么create（）的参数不像setProperties（）呢？

问题描述

对于Ember，我发现非常反直觉的是可以覆盖计算的属性设置器功能（），其参数为 create（）。请参阅

我发现最好的解决方法是调用 create（）。setProperties（properties）而不是 create（properties） / code>，但这似乎是一个不必要的骗子。我意识到这可能会打破一些应用程序，但是您会考虑使 create（）的行为更像是 setProperties（）？





我要求这个的动机是 init（）将在 create（）。setProperties（properties）模式时，setProperties（）这还没有成为一个大问题，但在某些情况下，我可以看到这是不合需要的。这是一个完全有创意的例子，但也许你可以看到我在做什么？

我可以看到维护当前行为的唯一原因是执行setter方法的实例特定覆盖。但是在这些情况下，您可以轻松地执行 MyClass.extend（{overridenMethod：...}）。create（properties）

会有这样的改变被认为是Ember 1.0？或者我只是想知道Ember的对象模型应该如何工作？

解决方案

我们推回的主要原因在这个变化上，它使得不可能将基类上定义的属性重写为计算属性。例如，在 Ember.View 中，模板属性是一个计算属性：

  template：Ember.computed（function（key，value）{
 if（value！== undefined）{return value;} 
 
 var templateName = get（this，'templateName'），
 template = this.templateForName（templateName，'template'）; 
 
返回模板|| get（this，' defaultTemplate'）; 
}）。property（'templateName'）。cacheable（），
  

当创建 Ember.View 的子类时，您可能需要使用显式模板函数覆盖此定义：

  Ember.View.create（{template：Ember.Handlebars.compile（'...'）}）; 
  

如果计算属性不处理setter情况，则尝试覆盖计算属性将一个无声的失败。

如果我们进行了这个更改，它还引入了其他问题，观察者是否应该触发传入创建方法。这两种方法都可以实现，而且对于这两种方法都有很强的争议。

在1.0之前，考虑一种方法，似乎是合理的： p>

• 更改创建使用 setProperties 语义


• 添加一个新的API（覆盖或 createWithOverride ）保留现有语义，以防您明确要覆盖现有的计算属性


• 抑制观察者为由于创建（或决定）找到一种方法来检测并警告关于使用不实现setter的计算属性的 create API的尝试。

我将需要更多地讨论它，并考虑对现有应用程序的影响，但这绝对值得考虑，因为它是绝对是新开发者的一个很大的骗子。事实上，我们需要改变 ember-data 的行为是一个很好的线索，一些事情是不正确的。

Something I find very counter-intuitive about Ember is you can overwrite a computed property setter functions ( http://emberjs.com/#toc_computed-properties-setters ) with the arguments to create(). See http://jsfiddle.net/zJQJw/2/

I found the best workaround for this is to call create().setProperties(properties) instead of create(properties), but this seems like an unnecessary gotcha to me. I realize it might break some apps at this point, but would you consider making create() behave more like setProperties()?

My motivation for asking for this is that init() will be called before setProperties() when using the create().setProperties(properties) pattern. This hasn't been a big problem yet, but I can see this being undesirable in some situations. This is a completely contrived example, but maybe you can see what I am getting at? http://jsfiddle.net/QJ8vX/2/

The only reason I can see for maintaining the current behavior is to do instance-specific overrides of setter methods. But in those cases you could just as easily do MyClass.extend({ overridenMethod: ... }).create(properties)

Would a change like this be considered for Ember 1.0? Or do I just have the wrong idea about how Ember's object model should work?

解决方案

The main reason why we've pushed back on this change is that it makes it impossible to override properties that are defined on base classes as computed properties. For example, in Ember.View, the template property is a computed property:

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(),

When creating a subclass of Ember.View, you may want to override this definition with an explicit template function:

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

If the computed property doesn't handle the setter case, this attempt to override the computed property would be a silent failure.

If we made this change, it also introduces other questions about whether observers should trigger for properties passed into the create method. Both are possible to implement, and there are strong arguments for both approaches.

In the run-up to 1.0, it seems reasonable to consider an approach that would:

• change create to use setProperties semantics
• add a new API (override or createWithOverride) that would retain the existing semantics, in case you explicitly wanted to override existing computed properties
• suppress observers for properties set due to create (or decide not to)
• find a way to detect and warn about attempts to use the create API with computed properties that do not implement setters.

I would need to discuss it more, and consider the implications to existing apps, but it is definitely something worth considering, as it is definitely a pretty big gotcha for new developers. The fact that we needed to change the behavior for ember-data is a pretty good clue that something isn't quite right.

这篇关于为什么create（）的参数不像setProperties（）呢？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！