Devoxx France 2014 – Au secours, mon code AngularJS est pourri !

Durant cette session 2014 de Devoxx France, je tenais particulièrement à assister au talk de Thierry Chatel Au secours, mon code AngularJS est pourri !

Derière ce nom un peut barbare Thierry nous y présentait les bonnes et mauvaises pratiques.

Je pratique AngularJS à plein temps depuis plus d'un an, et son retour sur les bonnes pratiques m'intéressait pour m'aider à éventuellement resituer "nos pratiques"

Pour faire court, je partage la même vision que Thierry, sauf sur un point mineur que je détaillerai en fin d'article.

Bonnes pratiques

Sans plus attendre, voici quelques points clé de la réussite d'une grosse (ou petite) application AngularJS:

- Pas d'optimisation prématurée

Ecrire du code pour gagner 3ms, cela rendrait le code moins lisible pour un gain...

- Effectuer le "binding" sur une fonction et non sur le résultat

Ne pas hésiter à rejouer plusieurs fois un traitement, cela allège le code et ce n'est souvent pas coûteux en ressources

- Ne pas hésiter à manipuler le JSON pour reconstruire un vrai model objet

- Si on a besoin de beaucoup de méthodes d'un service dans un écran

Ne pas hésiter à mettre ce service sur le scope

- Une arborescence fichier fonctionnel et non technique

- Définir les routes dans les différents modules, à la place d'un gros fichier de routes.

Cela facilite la lisibilité, et participe à isoler au maximum les modules.

- Le contrôleur ne sert qu'a initialiser le scope et faire le passe-plat vers les services

Cela est vrai pour presque tous les langages

- Ne pas hésiter à mettre plusieurs contrôleurs sur un écran

Un contrôleur sur un ng-repeat permet d'effectuer un traitement sur chaque item de la liste (par exemple pour un $watch)

- Pas de métier dans les contrôleurs, ni dans les templates

Ceci est du code "métier"
ng-class="{'foo': bar >= 100}"
Ceci n'en est pas 😀
ng-class="{'foo': bar.isFoo()}"

- Stocker des promises au lieu du résultat

Cela évite les traitements conditionnels pour savoir si la donnée est présente. Le code sera exécuté quand la promise sera résolue/

Conclusion

  • Faire au plus simple
  • Partir du html
  • Profiter un maximum de la "souplesse" du JavaScript
  • Coder en "Objet"

Petite divergence d'avis

Thierry nous préconise "1 fichier = 1 module" pour éviter d'avoir à gérer l'ordre de chargement des fichiers, et je suis d'accord avec lui pour faciliter le chargement.

Je suis plus pour utiliser des conventions de nommage (ex: monModule.mdl.js), ce qui me permet ensuite de charger les modules en premier avec les tâches Grunt ou Gulp.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.