# AngularJS - best practices
# Règles générales basiques
- Un fichier de source par ctrl / serv / direc
- Pas de logique dans les ctrl
- Pas de regles metier dans les templates. Passer par des services.
- 95% du code de l'appli doit être dans des services et couvert pas des TU
- Pas de manipulation du DOM ailleurs que dans une directive (compile ou link)
- follow angularjs-styleguide
# De jQuery à AngularJS
# Coding Style
- angularjs-google-style
- Règles chez Paypal
- Best-Practices
- angular-styleguide (John Papa)
- angular-styleguide (Minko Gechev)
- angularjs-styleguide (Todd Motto)
- opinionated-angular-js-styleguide-for-teams (Todd Motto)
# Git
# Module declaration
# Minification
# Controllers usage
# form validation
# Scaffolding
best scaffolding practices for generator-angular discussed here related to Angular Best Practice for App Structure (Google doc)
# Scaffolding comparison
# Architecture
Introduction to Angular 1.x and ngCourse
Rangle's Angular Training Book
# w3c-validation
should-i-care-about-w3c-validation
# Preparer migration Angular2
# Managing a model layer
# Au secours, mon code AngularJS est pourri ! - Thierry Chatel, Devoxx 2014
- attention aux composants
bcp de composants opensource, certains sont bons, d'autres très mauvais
- ne pas optimiser (sauf quand VRAIMENT nécessaire)
il propose de publier dans la vue avec des fonctions (donc plusieurs calculs à chaque digest)
- travailler le modèle
il parle du view model, et recommande donc de préparer le modèle à publier dans la vue et de ne pas publier directement le json
ne veut pas stocker non plus les données à publier dans le modèle
- service dans le scope
si beaucoup d'usage de fonctions d'un service dans une vue, se simplifier la vie et publier directement l'instance du service, ou bien écrire un service de façade ne contenant que la partie à publier
- structure de la webapp
ne pas organiser par type (controller/ directives/ services/ etc ...).
découpage fonctionnel, en bout de ligne découper en controller, directives, services.
1 fichier js = 1 module
- contrôleur
initialise le scope et rien d'autre.
sert à effectuer les bindings et c'est tout.
pas de traitement
pas de requetes http
liaison entre services et scope
doivent rester légers
syntaxe controllerAs
- services
contient tout le code métier et une bonne partie du code de présentation
pas de règles métiers dans les templates
permettent de conserver des données (car service = singleton) globales
si données concernent seulement une vue, ne pas les conserver et simplement les renvoyer.
utiliser les promesses pour les services asynchrones
découper les services en couches
- promesses
code unique qu'on soit en sync ou async
ne travailler que sur les promesses et pas les résultats
en cas d'échec : soit promesse en erreur soit throw une exception
- filtres
ne jamais modifier les données en entrée
- directives
priviléger les bindings aux maniplations du DOM
s'appuyer sur le html plutôt que de le remplacer ou de le générer
attributs html = interface de la directive
pas d'héritage implicite des données du scope, on passe par un attr de la directive
scope isolé
- tests
doit être aussi propre que le code applicatif
imbriquer les describe pour avoir des beforeEach communs (factorisation du code des tests) valable en e2e
e2e : factoriser les elementFinder
conclusion
faire simple :
- partir du html
- bien connaitre js
- faire un vrai modèle objet (bonnes pratiques POO)