¿Por qué los argumentos para crear() se comportan más bien como setProperties()?

Question

Algo que encuentro muy contrario a la intuición sobre Ember es que puede sobreescribir una función calculada de las funciones de configuración (http://emberjs.com/#toc_computed-properties-setters) con los argumentos a create(). Veo http://jsfiddle.net/zJQJw/2/

He encontrado la mejor solución para esto es llamar create().setProperties(properties) en lugar de create(properties), pero esto parece una Gotcha innecesaria para mí. Me doy cuenta de que podría romper algunas aplicaciones en este punto, pero ¿consideraría hacer que create() se comporte más como setProperties()?

Mi motivación para solicitar esto es que se llamará init() antes de setProperties() cuando se utiliza el patrón create().setProperties(properties). Este no ha sido un gran problema todavía, pero puedo ver que esto es indeseable en algunas situaciones. Este es un ejemplo completamente artificial, pero ¿quizás puedes ver a qué me refiero? http://jsfiddle.net/QJ8vX/2/

La única razón que puedo ver para mantener el comportamiento actual es realizar anulaciones específicas de instancias de métodos setter. Pero en esos casos, podría hacer tan fácilmente MyClass.extend({ overridenMethod: ... }).create(properties)

¿Se consideraría un cambio como este para Ember 1.0? ¿O simplemente tengo una idea equivocada sobre cómo debería funcionar el modelo de objetos de Ember?

Answer 1

La razón principal por la que hemos rechazado este cambio es que hace imposible anular las propiedades que se definen en las clases base como propiedades calculadas. Por ejemplo, en Ember.View, la propiedad template es una propiedad calculada:

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

Al crear una subclase de Ember.View, es posible que desee anular esta definición con una función de plantilla explícita:

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

Si el la propiedad calculada no maneja el caso del colocador, este intento de anular la propiedad calculada sería un error silencioso.

Si realizamos este cambio, también introduce otras preguntas sobre si los observadores deben activar las propiedades pasadas al método create. Ambos son posibles de implementar, y existen argumentos sólidos para ambos enfoques.

En el período previo a 1,0, parece razonable considerar un enfoque que:

• cambio create utilizar setProperties semántica
• añadir una nueva API (override o createWithOverride) que retendría el semántica existente, en caso de que explícitamente desee anular las propiedades calculadas existentes
• suprimir observadores para las propiedades establecidas debido a create (o decidir no hacerlo)
• encuentra una forma de detectar y advertir acerca de los intentos de usar la API create con propiedades calculadas que no implementan setters.

que tendría que discutir más, y considerar las implicaciones para las aplicaciones existentes, pero es definitivamente algo que vale la pena considerar, ya que es sin duda una muy grande de gotcha para los nuevos desarrolladores.El hecho de que necesitamos cambiar el comportamiento para ember-data es una pista bastante buena de que algo no está del todo bien.

Answer 2

Puede ser un truco sucio, pero me sirve.

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