Backbone: Agregar soporte de getter/setter para extender el método

Creado en 9 feb. 2015 · 12Comentarios · Fuente: jashkenas/backbone

Dado que los getters/setters son compatibles con IE9+ y serán mucho más frecuentes con ES6, sería bueno que el método de extensión de Backbone los admitiera.

var Person = Backbone.Model.extend({
  get fullName() {
    return this.get('firstName') + ' ' + this.get('lastName');
  }
});

var elonMusk = new Person({
  firstName: 'Elon', 
  lastName: 'Musk'
});

console.log(person.fullName); // >> Elon Musk

En este momento, esto daría como resultado undefined is not a function porque usar _.extend es llamar al captador.

change wontfix

Fuente

jamiebuilds

Comentario más útil

Claro, eso haré

jamiebuilds en 11 feb. 2015

❤2 🎉1

Todos 12 comentarios

¿Hay alguna razón por la que no podría escribirse mejor como person.fullName() para que sepa que es una llamada de función?

El uso de getters y setters es en su mayor parte una mala idea en JS, y van en contra de una de las ideas centrales de Backbone Models. Dudo que veas soporte agregado en el corto plazo.

akre54 en 9 feb. 2015

Más que nada, esto estaría parcialmente alineado con la nueva sintaxis de clase. No hay inicializadores de propiedad en la sintaxis de la clase o incluso ninguna especificación para ellos todavía, por lo que la interoperabilidad será un problema.

van en contra de una de las ideas centrales de Backbone Models.

¿Qué idea central es esa?

También los getters son una solución parcial a un problema existente en Backbone.Collection con model.idAttribute .

jamiebuilds en 9 feb. 2015

Pasé unos minutos tratando de hacer un jsperf con diferentes soluciones:
http://jsperf.com/backbone-extend-with-define-property

jamiebuilds en 9 feb. 2015

¿Qué idea central es esa?

La idea de que establecer y recuperar una propiedad en un objeto debe ser transparente y lógico para razonar. Siempre debe saber que obj.prop = val nunca hace otra cosa que establecer ese valor de propiedad (lo mismo para la recuperación), mientras que debemos usar funciones para manejar cosas como propiedades calculadas y eventos de cambio. Esa es la razón principal de los métodos de envoltura get y set alrededor attributes en primer lugar.

Además, los captadores son una solución parcial a un problema existente en Backbone.Collection con model.idAttribute.

¿Alguna razón por la cual el envoltorio _.result actual no funciona para esto? idAttribute puede ser una primitiva o una función. Esto también se está arreglando con modelId .

akre54 en 9 feb. 2015

Lo siento, debería haberme vinculado al problema del que estaba hablando: https://github.com/jashkenas/backbone/issues/3408

Menciono esto principalmente porque la sintaxis de clase de Backbone ya es en gran parte compatible con la sintaxis de clase ES, y parece razonable que sean compatibles considerando el soporte adicional para coffeescript.

jamiebuilds en 10 feb. 2015

CoffeeScript no es compatible con setters y getters en gran medida por las mismas razones (busque los problemas allí para conocer algunos antecedentes, comenzando con https://github.com/jashkenas/coffeescript/pull/2902). No deberían ser un obstáculo para admitir objetos Backbone como clases.

Lo siento, debería haber vinculado al problema del que estaba hablando: # 3408

¿Recuerdame? Me estoy esforzando por ver la conexión desde el principio.

Además, cualquier cambio en extend tendría que hacerse en _.extend , no aquí. Cerrando como un wontfix.

akre54 en 10 feb. 2015

CoffeeScript no admite setters y getters en gran parte por las mismas razones

No estaba hablando de getters/setters, estaba hablando de cómo Backbone agregó __super__ para la interoperabilidad con CoffeeScript, y cómo solo tiene sentido que sea compatible con las clases de ES6 de la misma manera.

¿Recuerdame? Me estoy esforzando por ver la conexión desde el principio.

Collection.extend({
  model: function() { return Model }
});
//
collection.modelId(model); // 'id' regardless if that's correct or not.

Collection.extend({
  get model() { return Model }
});
//
collection.modelId(model); // correct for *some* of the common cases.

Además, cualquier cambio para extender tendría que hacerse en _.extend, no aquí. Cerrando como un wontfix.

Definitivamente ese no es el lugar correcto para este cambio, en todo caso sería en el nuevo método _.assign . Pero tiene mucho más sentido que sea compatible aquí, en mi opinión.

Además, antes de que este problema se cierre y se olvide, me gustaría abordar por qué está bien que la extensión de Backbone tenga problemas de interoperabilidad con las clases ES pero no con las clases CoffeeScript.

jamiebuilds en 10 feb. 2015

Bueno, dado que IE Tech Preview es el único navegador con soporte incluso remotamente decente de class (incluso Traceur y 6to5 aún no convierten extends ), estamos muy lejos de esto incluso siendo necesario. Aparte de eso, Backbone no se esforzará por romper la compatibilidad con versiones anteriores solo para admitir una función que, para empezar, no es una gran idea.

akre54 en 10 feb. 2015

incluso Traceur y 6to5 aún no convierten extends

En realidad, ambos lo hacen, solo requieren soporte para __proto__ para propiedades estáticas que son ampliamente compatibles.

Además, no hay razón para romper la compatibilidad con palabras anteriores, incluso podría hacerse más rápido si usara selectivamente Object.setPrototypeOf cuando esté disponible.

jamiebuilds en 10 feb. 2015

@thejameskyle ¿Quiere convertir esto en relaciones públicas en lugar de un problema? Vale la pena mirar.