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.