Sylvain vous donne son astuce de code.
Les CP : un des concepts clés d’Ember.js. ! La documentation présente bien le sujet, mais je vous propose d’aller plus loin pour éviter certains petits pièges.
Voici 3 sujets qui peuvent compléter la documentation de base au sujet des Computed Properties :
1/ Définir correctement les dépendances
Dans l’idéal, si on utilise une propriété d’un objet dans une cp, cette propriété doit se retrouver dans les dépendances. Si on l’oublie, on peut se retrouver avec une cp non mise à jour, et donc un résultat faux.
var Person = Ember.Object.extend({
firstName: '',
lastName: '',
fullName: Ember.computed('firstName', function() {
return this.get('firstName') + ' ' + this.get('lastName');
})
})
p1 = Person.create({firstName: 'Tony', lastName: 'Parker' });
p1.get('fullName') // retourne "Tony Parker"
p1.set('lastName', 'Gobert');
p1.get('fullName') // retourne toujours "Tony Parker" car la cp n'a pas été invalidée.
2/ Cas de dépendance sur un tableau
cp1: Ember.computed('anArray', function(){ /*...*/})
Cette cp va être recalculée uniquement lorsque le tableau lui même change (this.set(‘anArray’, newArray)).
cp2: Ember.computed('anArray.[]', function(){ /*...*/})
Cette cp va être recalculée dans le même cas que cp1, mais aussi lorsqu’on manipule le tableau (ajout, suppression, échange d’éléments dans le tableau).
cp3: Ember.computed('[email protected]', function(){ /*...*/})
Cette cp va être recalculée même cas que cp1 et cp2, mais aussi lorsque la valeur de la propriéte ‘someProperty’ d’un élément du tableau change.
Faire la distinction entre ces trois cas d’utilisation est importante, et peut réduire des éventuels problèmes de performances.
Par exemple, utiliser la troisième forme, et être notifié d’un grand nombre de changements alors qu’on a seulement besoin de l’être lors d’un changement du tableau
3/ Attention à ne pas effacer la cp
Lorsqu’on modifie une propriété d’un objet (via objet.set(‘someProperty’, ‘abc’), et que celle-ci est une cp, alors on écrase tout simplement le comportement initial. La propriété devient ainsi une propriété statique et n’est plus recalculée. Dans une application de grande taille, ce piège est finalement assez courant (en tous cas, ça m’est arrivé plusieurs fois…).
Encore une fois, plusieurs solution se présentent:
– Définir le setter de la cp
Dans le cas (minoritaire) ou la modification de la cp est voulue, il faut bien penser à définir le setter de la cp (voir « Setting Computed Properties »). De cette manière, lorsque l’une de ses dépendance sera modifiée, la cp sera bien mise à jour.
– Définir la cp en mode readOnly()
Dans le cas (majoritaire) ou la modification de la cp est accidentelle, alors il est préférable de marquer la cp en Lecture seule. De cette manière, lorsque par inadvertance quelqu’un tentera de la modifier, une erreur sera lancée. Cela évite des bugs subtils et fait économiser du temps de debug… 🙂
Vous souhaitez en savoir plus sur son auteur ? Suivez-le sur Twitter :
Envie de partager votre astuce de code ?
