Backbone: Ajouter le support getter/setter pour étendre la méthode

Créé le 9 févr. 2015 · 12Commentaires · Source: jashkenas/backbone

Étant donné que les getters/setters sont pris en charge par IE9 + et seront beaucoup plus répandus avec ES6, ce serait bien si la méthode d'extension de Backbone les prenait en charge.

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

À l'heure actuelle, cela se traduirait par undefined is not a function car l'utilisation _.extend appelle le getter.

change wontfix

Source

jamiebuilds

Commentaire le plus utile

Bien sûr, je vais le faire

jamiebuilds le 11 févr. 2015

❤2 🎉1

Tous les 12 commentaires

Y a-t-il une raison qui ne pourrait pas être mieux écrite comme person.fullName() pour que vous sachiez que c'est un appel de fonction ?

L'utilisation de getters et de setters est pour la plupart une mauvaise idée dans JS, et ils vont à l'encontre de l'une des idées fondamentales des modèles Backbone. Je doute que vous voyiez un support ajouté de si tôt.

akre54 le 9 févr. 2015

Plus que tout, cela serait partiellement aligné avec la nouvelle syntaxe de classe. Il n'y a pas encore d'initialiseurs de propriété dans la syntaxe de la classe ni même de spécification pour eux, donc l'interopérabilité sera un problème.

ils vont à l'encontre d'une des idées fondamentales des Backbone Models.

De quelle idée principale s'agit-il ?

Les getters sont également une solution partielle à un problème existant dans Backbone.Collection avec model.idAttribute .

jamiebuilds le 9 févr. 2015

J'ai passé quelques minutes à essayer de créer un jsperf avec différentes solutions :
http://jsperf.com/backbone-extend-with-define-property

jamiebuilds le 9 févr. 2015

De quelle idée principale s'agit-il ?

L'idée selon laquelle la définition et la récupération d'une propriété sur un objet doit être transparente et logique pour raisonner. Vous devez toujours savoir que obj.prop = val ne fait jamais autre chose que de définir cette valeur de propriété (idem pour la récupération), alors que nous devrions utiliser des fonctions pour gérer des choses comme les propriétés calculées et modifier les événements. C'est la raison principale des méthodes wrapper get et set autour attributes en premier lieu.

Les getters sont également une solution partielle à un problème existant dans Backbone.Collection avec model.idAttribute.

Une raison pour laquelle le wrapper _.result actuel ne fonctionne pas pour cela ? idAttribute peut être une primitive ou une fonction. Ceci est également corrigé avec modelId .

akre54 le 9 févr. 2015

Désolé, j'aurais dû créer un lien vers le problème dont je parlais : https://github.com/jashkenas/backbone/issues/3408

J'en parle principalement parce que la syntaxe de classe de Backbone est largement déjà compatible avec la syntaxe de classe ES, et il semble raisonnable qu'elles soient compatibles compte tenu de la prise en charge supplémentaire de coffeescript.

jamiebuilds le 10 févr. 2015

CoffeeScript ne prend pas en charge les setters et les getters en grande partie pour les mêmes raisons (regardez les problèmes là-bas pour un peu de fond, en commençant par https://github.com/jashkenas/coffeescript/pull/2902). Ils ne devraient pas être un obstacle à la prise en charge des objets Backbone en tant que classes.

Désolé, j'aurais dû mettre un lien vers le problème dont je parlais : #3408

Rappelle moi? Je m'efforce de voir la connexion dès le départ.

De plus, toute modification de extend devrait être effectuée dans _.extend , pas ici. Fermeture comme une coutume.

akre54 le 10 févr. 2015

CoffeeScript ne prend pas en charge les setters et les getters en grande partie pour les mêmes raisons

Je ne parlais pas des getters/setters, je parlais de la façon dont Backbone a ajouté __super__ pour l'interopérabilité avec CoffeeScript, et comment il est logique qu'il prenne en charge les classes ES6 de la même manière.

Rappelle moi? Je m'efforce de voir la connexion dès le départ.

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.

De plus, toute modification à étendre devrait être effectuée dans _.extend, pas ici. Fermeture comme une coutume.

Ce n'est certainement pas le bon endroit pour ce changement, si quoi que ce soit, ce serait dans la nouvelle méthode _.assign . Mais il est beaucoup plus logique qu'il soit pris en charge ici IMO.

De plus, avant que ce problème ne soit clos et oublié, j'aimerais expliquer pourquoi il est normal que l'extension de Backbone ait des problèmes d'interopérabilité avec les classes ES mais pas avec les classes CoffeeScript.

jamiebuilds le 10 févr. 2015

Eh bien, vu qu'IE Tech Preview est le seul navigateur avec une prise en charge même à distance décente de class (même Traceur et 6to5 ne convertissent pas encore extends ), nous sommes loin d'être nécessaire. Cela mis à part, Backbone ne fera pas tout son possible pour briser la rétrocompatibilité juste pour prendre en charge une fonctionnalité qui n'est pas une bonne idée pour commencer.

akre54 le 10 févr. 2015

même Traceur et 6to5 ne convertissent pas encore extends

En fait, ils le font tous les deux, ils ont juste besoin de la prise en charge de __proto__ pour les propriétés statiques qui sont largement prises en charge.

De plus, il n'y a aucune raison pour que la compatibilité des backwords soit interrompue, elle pourrait même être rendue plus rapide si elle utilisait sélectivement Object.setPrototypeOf là où elle était disponible.

jamiebuilds le 10 févr. 2015

@thejameskyle Vous voulez transformer cela en relations publiques plutôt qu'en problème ? Cela vaut la peine d'être regardé.