[AngularJS Git Commit Message] (https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit?pli=1)
[big resume] (http://www.ng-newsletter.com/posts/validations.html)
best scaffolding practices for generator-angular discussed here related to Angular Best Practice for App Structure (Google doc)
Introduction to Angular 1.x and ngCourse
Rangle's Angular Training Book
[should-i-care-about-w3c-validation] (http://stackoverflow.com/questions/18607437/should-i-care-about-w3c-validation)
bcp de composants opensource, certains sont bons, d'autres très mauvais
il propose de publier dans la vue avec des fonctions (donc plusieurs calculs à chaque digest)
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
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
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
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
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
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
ne jamais modifier les données en entrée
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é
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 :