Вопрос по ember.js – Почему аргументы create () не ведут себя больше как setProperties ()?

12

Что-то, что я нахожу очень нелогичным в Ember, это то, что вы можете перезаписать вычисляемые функции установщика свойств (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/

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

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

Я подалаgithub.com/emberjs/ember.js/issues/777так что не стесняйтесь звонить вон там. Adam Murray
некоторые из нас здесь также обсуждали это с командой ember, и они в основном сказали, что не меняют ее. Я с тобой согласен. Lance Pollard
Я поднял эту точную проблему на канале, в основном академически, и ответ был (перефразируя) «Я не вижу, как мы меняем поведение create». Однако я бы посоветовал вам открыть дискуссионную тему на github. Christopher Swasey
Кто-то спросил, почему я хотел использовать вычисляемые функции установщика свойств, и одна из причин состояла в том, чтобы обеспечить, что двунаправленные отношения всегда действительны. Теперь я прибег к созданию собственного метода .setFoo (value) вместо того, чтобы использовать шаблон с более естественным ощущением .set ('foo & apos ;, value). Мне не нравится несоответствие, потому что оно сбивает с толку людей, которые не пишут код, но должны его использовать. Но это работает. Это просто кажется одной из тех особенностей, на которые люди будут жаловаться вечно ... о, хорошо. Adam Murray

Ваш Ответ

2   ответа
10

по которой мы отодвинули это изменение, состоит в том, что он делает невозможным переопределение свойств, определенных в базовых классах, в качестве вычисляемых свойств. Например, в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 кажется разумным рассмотреть подход, который бы:

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.

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

Я хотел бы знать, если это такая же проблема, какstackoverflow.com/questions/11412550/…
Это касается только до 1.0.create() был изменен на использованиеsetProperties() here, Новый API, который использует старую семантикуcreateWithMixins().
Спасибо за подробный ответ, Иегуда. Мне интересно посмотреть, как это может быть решено в будущей версии. Пули, которые вы перечислили, звучат многообещающе. Adam Murray
4

Em.Object.reopenClass({ 
   create: function(config) {
       return this._super().setProperties(config); 
   }
});
Хм, это мой вид взлома. Реализация.

Похожие вопросы