Angular, TL;DR en fr

Ça fait plusieurs fois que je parle d'Angular sur mon blog. AprĂšs avoir enfin avoir travaillĂ© avec professionnellement, voici quelques pensĂ©es sur ce framework et ce qui l'entoure.

Au final, travailler avec Angular était intéressant, et je trouve qu'Angular est un framework contradictoire.

Il a tout pour ĂȘtre accessible (CLI, TypeScript...) mais mĂ©lange tout ça avec des concepts avancĂ©s qui peuvent perdre les dĂ©veloppeurs dĂ©butants; concepts parfois excessifs pour pas grand chose (observables).

⚠ je dis plein de bĂȘtises.

Formation

J'avais suivi la SFEIR School il y a quasiment 3 ans et c'Ă©tait bien.

Avant de démarrer le projet je m'y suis remis avec Become a ninja with Angular, c'est une magnifique ressource.

TypeScript

On peut coder avec Angular en ES5 et ES2015, mĂȘme si ce n'est pas pratique. La recommandation est Ă©videmment TypeScript.

J'ai écrit précédemment que je ne comprenais pas TypeScript. J'ai évolué un peu et j'ai trouvé que c'est plutÎt chouette à l'utilisation. Je reste convaincu qu'il y a de meilleurs outils pour répondre au besoin qu'il tente de solutionner, par exemple Flow, qui conviendra mieux aux amoureux de JavaScript à mon avis.

Modules et composants

Aujourd'hui, on ne peut pas faire autrement qu'avec des composants. Tous les frameworks fonctionnent de cette façon. Angular permet de définir des modules afin de bien découper son application.

Pouvoir dĂ©couper l'application en modules, c'est bien. Devoir lier tous les composants Ă  la racine du module, c'est moins bien (mĂȘme si la CLI le fait pour nous).

J'adore l'idée des Angular Elements bien que je n'ai pas eu à les utiliser.

CLI

Le CLI ne laisse pas le choix de rĂ©flĂ©chir Ă  l’architecture.

Un petit tweet de Dan Abramov ne fait jamais de mal. À propos d'une discussion sur comment organiser ses fichiers, il a sorti ceci et voici son conseil:

C'est une ligne directrice. Cela signifie littĂ©ralement «commencez par tout mettre dans un seul fichier; quand cela vous semble agaçant, commencez Ă  les sĂ©parer; que CELA devient agaçant, ajoutez peut-ĂȘtre des dossiers ”.

Le CLI d'Angular est intĂ©ressant pour rĂ©pondre au point sur les composants qu'il faut forcĂ©ment indiquer dans les modules mais... Pour les habituĂ©s de react / vue, oĂč un composant est importĂ© directement dans le composant parent sans avoir Ă  le dĂ©clarer tout en haut de la chaĂźne, ce n'est pas naturel.

J'aime bien le principe des schematics cependant.

NGXS

Suite à une recommandation de quelques collÚgues, nous avons utilisé NGXS pour gérer nos données dans l'application.

Ayant travaillĂ© avec d'autres frameworks — React avec Redux[^1] et Vue avec Vuex — j'ai trouvĂ© la librairie NGXS trĂšs inconfortable. TrĂšs compliquĂ© de faire fonctionner le tout avec uniquement la documentation.

Une action équivaut à instancier une classe... Pourquoi faire simple quand on peut faire compliqué ?

[^1]: j'aime l'idĂ©e du pattern amenĂ© avec Redux, mais je ne suis pas fan de la mise en place. J'en parlerai peut ĂȘtre une autre fois.

Tests

Je n'avais pas eu de souci avec Angular.js quand j'Ă©tais jeune, mĂȘme si certains de mes collĂšgues trouvaient ça «lourd».

En Angular, c'est encore pire. La mise en place des tests est insupportable pour continuer de respecter le Saint Graal qu’est l’injection de dĂ©pendances. Les tests sont beaucoup plus agrĂ©ables Ă  Ă©crire en react ou vue.

Observables

Les observables répondent à quelque chose de précis, et Angular a fait le choix de les utiliser pour tout.

Je parle souvent de devoir utiliser quelque chose qui répond à un besoin, et utiliser les Observables pour tout, non merci.

Formulaires

Pour les formulaires c’est bien, parce que ça rend les choses faciles. C’est peut-petre dommage de ne pas ĂȘtre plus « difficile » et de laisser plus de choses Ă  gĂ©rer Ă  la main.

Les validateurs sont bien pratiques Ă  utiliser. J'avais dĂ©jĂ  bien jouĂ© avec Angular.js grĂące Ă  cet article, et j'ai retrouvĂ© le mĂȘme plaisir Ă  faire des trucs bizarres avec les validateurs dans Angular.