Почему аргументы create() больше не похожи на setProperties()?

Что-то, что я нахожу очень интуитивно понятным в отношении Ember, вы можете перезаписать функции setput set setter (http://emberjs.com/#toc_computed-properties-setters) с аргументами create(). См. http://jsfiddle.net/zJQJw/2/

Я нашел, что лучшим решением для этого является вызов create().setProperties(properties) вместо create(properties), но для меня это кажется ненужным. Я понимаю, что это может сломать некоторые приложения на данный момент, но рассмотрите ли вы возможность сделать create() более похожим на setProperties()?

Мотивация для этого заключается в том, что init() будет вызываться до setProperties() при использовании шаблона create().setProperties(properties). Это еще не было большой проблемой, но я вижу, что это нежелательно в некоторых ситуациях. Это надуманный пример, но, может быть, вы можете видеть, что я получаю? http://jsfiddle.net/QJ8vX/2/

Единственная причина, по которой я могу наблюдать за текущим поведением, - это переопределить специфические для экземпляра методы setter. Но в таких случаях вы можете так же легко сделать MyClass.extend({ overridenMethod: ... }).create(properties)

Будет ли такое изменение рассмотрено для Ember 1.0? Или у меня есть неправильное представление о том, как должна работать модель объекта Ember?

Ответ 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('...') });

Если вычисленное свойство не обрабатывает случай сеттера, эта попытка переопределить вычисленное свойство будет молчащим сбоем.

Если мы внесем это изменение, оно также вводит другие вопросы о том, должны ли наблюдатели запускать свойства, переданные в метод create. Оба варианта можно реализовать, и для обоих подходов есть веские аргументы.

В преддверии 1.0 кажется разумным рассмотреть подход, который:

изменить create на использование семантики setProperties
добавить новый API (override или createWithOverride), который сохранит существующую семантику, если вы явно хотите переопределить существующие вычисленные свойства
подавлять наблюдателей для свойств, установленных из-за create (или не принимать)
найти способ обнаружения и предупреждения о попытках использовать API create с вычисленными свойствами, которые не реализуют сеттеры.

Мне нужно будет обсудить это больше и подумать о последствиях для существующих приложений, но это определенно заслуживает рассмотрения, так как это определенно довольно большая новость для новых разработчиков. Тот факт, что нам нужно было изменить поведение для ember-data, - довольно хорошая подсказка, что что-то не так.

Ответ 2

Это может быть грязный хак, но он работает для меня.

Em.Object.reopenClass({ 
   create: function(config) {
       return this._super().setProperties(config); 
   }
});