Backbone: Adicione suporte a getter/setter para estender o método

Criado em 9 fev. 2015 · 12Comentários · Fonte: jashkenas/backbone

Como getters/setters são suportados pelo IE9+ e serão muito mais prevalentes com o ES6, seria bom se o método extend do Backbone os suportasse.

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

No momento, isso resultaria em undefined is not a function porque usar _.extend é chamar o getter.

change wontfix

Fonte

jamiebuilds

Comentários muito úteis

Claro, vou fazer isso

jamiebuilds em 11 fev. 2015

❤2 🎉1

Todos 12 comentários

Existe algum motivo que não poderia ser melhor escrito como person.fullName() para que você saiba que é uma chamada de função?

Usar getters e setters é, na maioria das vezes, uma má ideia em JS, e vai contra uma das ideias centrais dos Modelos de Backbone. Duvido que você verá o suporte adicionado em breve.

akre54 em 9 fev. 2015

Mais do que tudo, isso seria parcialmente alinhado com a nova sintaxe de classe. Ainda não há inicializadores de propriedade na sintaxe da classe ou mesmo qualquer especificação para eles, portanto, a interoperabilidade será um problema.

eles vão contra uma das ideias centrais dos Modelos de Backbone.

Que ideia central é essa?

Também os getters são uma solução parcial para um problema existente no Backbone.Collection com model.idAttribute .

jamiebuilds em 9 fev. 2015

Passei alguns minutos tentando fazer um jsperf com soluções diferentes:
http://jsperf.com/backbone-extend-with-define-property

jamiebuilds em 9 fev. 2015

Que ideia central é essa?

A ideia de que definir e recuperar uma propriedade em um objeto deve ser transparente e lógico para se raciocinar. Você deve sempre saber que obj.prop = val nunca faz nada além de definir esse valor de propriedade (idem para recuperação), enquanto devemos usar funções para lidar com coisas como propriedades computadas e eventos de alteração. Essa é a principal razão para os métodos wrapper get e set em torno attributes em primeiro lugar.

Também os getters são uma solução parcial para um problema existente no Backbone.Collection com model.idAttribute.

Algum motivo para o atual wrapper _.result não funcionar para isso? idAttribute pode ser uma primitiva ou uma função. Isso também está sendo corrigido com modelId .

akre54 em 9 fev. 2015

Desculpe, eu deveria ter vinculado ao problema sobre o qual eu estava falando: https://github.com/jashkenas/backbone/issues/3408

Estou trazendo isso principalmente porque a sintaxe de classe do Backbone já é amplamente compatível com a sintaxe de classe ES, e parece razoável que sejam compatíveis considerando o suporte adicional para coffeescript.

jamiebuilds em 10 fev. 2015

CoffeeScript não suporta setters e getters em grande parte pelos mesmos motivos (procure os problemas lá para obter alguns antecedentes, começando com https://github.com/jashkenas/coffeescript/pull/2902). Eles não devem ser um obstáculo para suportar objetos Backbone como classes.

Desculpe, eu deveria ter vinculado ao problema sobre o qual eu estava falando: #3408

Lembre-me? Estou me esforçando para ver a conexão logo de cara.

Além disso, qualquer alteração em extend teria que ser feita em _.extend , não aqui. Fechando como um wontfix.

akre54 em 10 fev. 2015

CoffeeScript não suporta setters e getters em grande parte pelos mesmos motivos

Eu não estava falando sobre getters/setters, eu estava falando sobre como o Backbone adicionou __super__ para interoperabilidade com CoffeeScript, e como só faz sentido para ele suportar classes ES6 da mesma maneira.

Lembre-me? Estou me esforçando para ver a conexão logo de cara.

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.

Além disso, qualquer alteração para estender teria que ser feita em _.extend, não aqui. Fechando como um wontfix.

Esse definitivamente não é o lugar certo para essa mudança, se alguma coisa seria no novo método _.assign . Mas faz muito mais sentido que seja suportado aqui IMO.

Além disso, antes que esse problema seja encerrado e esquecido, gostaria de abordar por que não há problema em a extensão do Backbone ter problemas de interoperabilidade com classes ES, mas não com classes CoffeeScript.

jamiebuilds em 10 fev. 2015

Bem, visto que o IE Tech Preview é o único navegador com suporte remotamente decente de class (mesmo Traceur e 6to5 ainda não convertem extends ), estamos longe disso mesmo necessário. Além disso, o Backbone não vai se esforçar para quebrar a compatibilidade com versões anteriores apenas para oferecer suporte a um recurso que não é uma ótima ideia para começar.

akre54 em 10 fev. 2015

mesmo Traceur e 6to5 ainda não convertem extends

Ambos, na verdade, exigem apenas suporte para __proto__ para propriedades estáticas que são amplamente suportadas.

Também não há razão para que a compatibilidade de backwords precise ser quebrada, ela poderia até ser mais rápida se usasse seletivamente Object.setPrototypeOf quando disponível.

jamiebuilds em 10 fev. 2015

@thejameskyle Quer transformar isso em um PR em vez de um problema? Vale a pena olhar.