:::: MENU ::::

Migrer de AngularJS 1.x vers AngularJS 2.0 : la théorie

Tout ceux qui travaillent avec AngularJs aujourd’hui le savent ( ou devraient le savoir ) : AngularJS 1.x va mourir ! Certains ont eu du mal à digérer l’annonce lors de la ng-europe en octobre 2014 puisque Angularjs 2 est une rupture massive avec la version actuelle.  C’est alors qu’on a vu apparaître de plus en plus d’articles anti AngularJS mettant en avant la plupart de ses défauts.

Faut il pour autant laisser tomber AngularJs dans sa branche 1.x ? ou bien réécrire toutes ses applications « from scratch » avec une autre techno ? Attendre Angular 2 ?

Dans cette première partie je vais tenter de répondre aux questions que l’on peut se poser puis je vous montrerai en détail comment il est possible de préparer cette migration sereinement.

La mort du framework ?

Pas de panique, même si AngularJS 1.x et la plupart de ses concepts fondateurs vont disparaître, ce n’est pas pour tout de suite . A première vue, on pourrait se sentir trahi par l’équipe de dev d’Angular, mais honnêtement cette rupture est une bonne chose.

Keep-Calm-and-Hope-for-the-Best

AngularJS 2 s’annonce être pratiquement un nouveau framework et il n’aura plus grand chose à voir avec la version actuelle, c’est un fait. Mais l’écosystème autour des applications web évoluant, c’était une nécessité. En effet les fonctionnalités proposées dans Angular 1 comme par exemple les modules n’ont plus lieux d’être avec l’arrivée d’Ecmascript 6 2015. Bien que pas encore tout à fait finalisés, ce sont les fondations des futurs standards du développement web .

Vouloir implémenter une solution parallèle serait donc contre productif. Enfin n’oublions pas que AngularJS date de 2009, à l’époque et jusqu’à présent, ces apports étaient tout à fait pertinents.

AngularJs 2.0 le renouveau

Même si beaucoup de chemin reste à parcourir, on en sait maintenant un peu plus sur l’avenir du framework depuis la dernière ng-conf. Jusqu’à présent les annonces étaient discrètes voir maladroites et il fallait souvent se contenter de débats et drafts techniques. Désormais il est même possible de tester Angular 2 notamment à travers de ce quickstart officiel. On peut aussi se faire une idée en naviguant sur la documentation qui décrit la nouvelle API du framework .

Qu’est ce qui va changer ?

En fait, la plupart des concepts sont revus et une nouvelle syntaxe est même proposée. Je ne parlerai pas du débat autour de Atscript mais sachez qu’il sera possible de coder avec ES5 ou ES6 bien que Typescript semble conseillé . Le fait de l’utiliser permet l’ajout des annotations et du typage mais si vous avez déjà franchi le pas avec Ecmascript 6 alors vous ne serez pas vraiment dépaysé.

La détection des changements

Actuellement, lorsqu’on utilise le data-binding d’Angular, on enregistre un ou des watchers sur un objet, une propriété ou une fonction. Pour savoir si un changement est survenu et si une mise à jour de la vue doit intervenir, Angular effectue un test sur toutes valeurs observées à chaque fois qu’une donnée est susceptible d’avoir changé . C’est ce qu’on appel le dirty-checking. Le problème de cette méthode c’est que la performance se dégrade proportionnellement aux nombre d’objets que l’on observe.

Avec angularjs 2, le changement de détection est fait de manière asynchrone et sous forme d’arbre. C’est à dire que chaque composant qui comporte des bindings gère lui même les changements à l’aide de la méthode Object.observe() et propage l’information aux composants parents. De cette manière, la détection n’a pas d’impacte sur l’ensemble de l’application.

En plus de ça, le nouveau système supporte le concept des objets immuables ce qui améliore encore un peu plus les performances que l’on peut estimer à un facteur 10.

La fin des Contrôleurs

Angularjs 2 supprime la notion de contrôleur telle qu’on la connait actuellement pour la remplacer par des composants. C’est une approche plus contemporaine puisque de nombreuses librairies ont déjà franchies le pas comme c’est le cas avec Backbones ou React . La notion de MVC n’est plus tellement d’actualité dans le développement d’interfaces et on parle justement de plus en plus de composants ( les web components en sont l’exemple parfait ) . Pour faire simple on transforme le model MVC en model MV, et c’est ce qu’on appel un composant.

Plus de jQlite

L’équipe de développement estime que les API natives du DOM sont assez matures pour se passer d’une interface spécifique. Cela impose l’utilisation de navigateurs récents  mais la rétrocompatibilité n’est clairement pas l’objectif d’Angularjs 2 .

De nouvelles Directives

Angularjs 2 distingue désormais trois types de directive :

  • Component directive est ce qui se rapproche le plus des directives actuelles et correspond en fait à un couple controleur / template (nos fameaux « composants » )
  • Decorator directive permet d’ajouter des fonctionnalité à un élément HTML existant (ex : ng-show)
  • Template Directive rend un élément HTML dynamique et réutilisable ( ex : ng-repeat )

Voila un aperçu des principaux changements. Bien sur il en reste d’autres comme le nouveau routeur ou encore un système d’injection interchangeable.

Faut il migrer vers AngularJs 2.0 ?

La question peut se poser, dès lors que de nombreux concepts changent investir dans la version 1 qui va disparaître peut sembler une perte de temps..

La première chose à savoir est que AngularJs dans sa branche actuelle continue d’évoluer et de proposer des mises à jours . De plus, les nouveautés apportées à partir de la version 1.4 seront souvent construites pour faciliter la migration avec la prochaine version majeure.

Deuxième chose importante, Angularjs 2.0 n’est absolument pas terminé, l’API est en constante évolution et beaucoup de changements sont à prévoir.

Angular 2 is currently in Developer Preview. We recommend using Angular 1.X for production applications.

La réponse est donc : NON , il ne faut pas migrer vers Angularjs 2 pour le moment sauf dans le cadre d’une veille techno ou d’un POC.

Est ce que je vais devoir réécrire mon application développée sous Angularjs 1.x ?

Quand on regarde à quoi va ressembler Angular 2 c’est encore une question qu’on peut se poser. Vu le choc de certains après la première conférence sur le sujet , on pourrait même avoir envie, quitte à tout refaire, de se tourner vers d’autres solutions.

no-way

Sans en arriver à tout refaire, il y a de nombreuses façons d’adapter son code sous Angularjs 1.x . Sans réécrire entièrement son application, on peut l’améliorer par étapes, voir dans le cas d’un nouveau développement utiliser ce qui suit comme des bases, la plupart étant issues de bonnes pratiques.

Préparer la migration vers AngularJs 2.0

Avant de rentrer dans la technique voici deux points qu’il convient de respecter dès lors qu’on utilise des librairies ou frameworks, et ce quelque soit le langage employé. Ce sera dans tous les cas un gain non négligeable pour la suite.

Chacun à sa place

Une des première chose à faire est de connaitre un minimum son outil avant de s’y lancer à 100% et surtout d’en dépendre. C’est encore plus vrai dans le cas d’un framework qui apporte en général une couche supplémentaire. Au début le databinding bi-directionnel d’Angular semble magique, les directives une révolution et l’aspect structurant une nécessité quand on commence à construire une application complexe.

Mais pour toute magie en informatique il y a un prix et généralement celui d’un framework n’est pas à prendre à la légère. AngularJs impose une structure et des concepts mais ne protège en cas de mauvais usage de ceux ci.

Il faut toujours utiliser un outil pour ce qu’il peut apporter à son besoin et non contraindre son besoin à un framework ou une librairie.

La question à se poser : ais je besoin d'un framework ?

La question à se poser : ai- je besoin d’un framework ?

Les trois grands piliers d’Angular sur sa branche 1 sont :

  • les directives pour travailler avec le DOM
  • les contrôleurs pour gérer les vues et la connexion avec les modèles de données et les services
  • les services  pour contenir la logique de l’application 

Cela revient à

  • Limiter l’usage des fonctions touchant au DOM dans les directives .
  • Laisser uniquement des fonctions liées à la vue dans les contrôleurs sans effectuer des traitements entraînants la modification de l’état de l’application.
  • Garder la logique applicative et « métier » dans les services

De cette manière il sera plus simple lors de la migration d’identifier les différentes parties de l’application à déplacer voir réécrire.

Limiter le couplage

C’est une pratique qui apporte toujours une meilleure qualité de code. Limiter et encapsuler des composants applicatifs permet non seulement une meilleure maintenabilité générale mais rend aussi le code plus portable et testable . Le couplage peut intervenir à plusieurs niveaux mais ici on parle de la relation entre un programme et un framework tiers. De manière générale il est préférable de limiter ce qui vient du framework et qui n’est pas directement indispensable à l’application et préférer l’usage du natif si l’apport n’est pas notable. En cas de migration, la quantité de code à réécrire ne sera que diminuée.

Par exemple, dans le cas d’AngularJs voici ce qui va disparaître dans la version 2 :

RIP features from Angularjs 1

 

Si vous avez bien lu le paragraphe précédent, cela touche directement à deux des trois piliers de la version actuelle ! D’où la nécessité de maîtriser sa dépendance avec Angular .

Doctor-Who

Heureusement une solution existe pour chaque élément, c’est ce que nous verrons dans la seconde partie .

Notes:
1. le support de la branche 1 est prévu jusqu’en 2018 ce qui laisse largement le temps de migrer
2. en arrière plan, angular garde une image de la valeur de l’objet en mémoire et la compare avec la valeur courante
3. les vérifications des watchers sont fait dans ce qu’on appel une boucle de $digest. Elle intervient sur les appels ajax, les actions utilisateurs et plus généralement tout ce qui passe par angular
5. les services avec Angulars peuvent prendre différentes formes : provider, factory, service et encore value et constant
6. l’usage des sélecteurs CSS et traitements liés au DOM doit être restreint à la fonction link des directives
7. DDO signifiant Directive definition object c’est à dire tout ce qui concerne la description d’une directive
le support de la branche 1 est prévu jusqu’en 2018 ce qui laisse largement le temps de migrer
en arrière plan, angular garde une image de la valeur de l’objet en mémoire et la compare avec la valeur courante
les vérifications des watchers sont fait dans ce qu’on appel une boucle de $digest. Elle intervient sur les appels ajax, les actions utilisateurs et plus généralement tout ce qui passe par angular
les services avec Angulars peuvent prendre différentes formes : provider, factory, service et encore value et constant
l’usage des sélecteurs CSS et traitements liés au DOM doit être restreint à la fonction link des directives
DDO signifiant Directive definition object c’est à dire tout ce qui concerne la description d’une directive

11 Comments

  • Répondre Maxime |

    Je n’ai pas enormement d’experience en Angularjs, seulement 2 mois. J’apprécie beaucoup la techno. J’ai l’intention de commencer un projet en utilisant angularjs mais au vu de l’arrivé de la version 2, je ne sais pas quoi faire. Rester en angular 1.x ? Ou directement le faire en 2 ?

  • Répondre maxdow |

    Le mieux est de se tenir informer sur les changements introduits par Angular 2. L’article concernant la migration 1 > 2 est en cours , il faut juste que je trouve le temps de le terminer.

    Une chose est sure concernant angular 1 , le data-binding bidirectionnel tel qu’il existe n’est pas reporté dans la V2 , et c’est une bonne chose ! A moins d’avoir un schéma de donnée et d’édition exactement similaire à ce qu’on veut présenter, cela finit par devenir complexe et la magie du début s’estompe vite.
    Sinon pour le reste, la meilleur technique à adopter est de limité l’adhérence avec le framwork. Un code javascript « pure » sera le même pour Angular 1 ou 2 .

    Il est préconisé pour le moment de rester sur Angular 1 . L’équipe prévoit la possibilité de migrer vers Angular 2 par morceaux ( routage, directives , services.. ) ce qui rendra l’évolution plus souple en faisant cohabiter temporairement les 2 version.

    En réponse donc , il faut se poser la question : Quels sont les éléments qui nécessitent angularjs ?

    Ensuite , sur ces éléments la, quels seront les points de couplages avec le framework. Ces points devant être surveillés et prévus pour adaptation avec la V2 mais en restant pour le moment sur une V1.x

    • Répondre maxdow |

      Merci :) elle est en cours de rédaction, il manque juste un peu de disponibilité . Vu que la V2 est encore loin d’être sur le marché, il y a encore un peu de marge.
      Globalement la réponse c’est : découpler un maximum .

    • Répondre admin |

      Je ne l’ai pas encore testé . Sa force je pense est de prendre le parti dès son origine de se tourner vers toutes les nouveautés présentes ou à venir (décorateurs, modules … ) . A terme je me pose quand même la question face à Angular 2..

  • Répondre Clarky Kenty |

    Bonjour, je pense que tu devrais montrer des exemples de code Angular 1 et 2 pour mieux appuyer les différences.

    • Répondre admin |

      Bonjour,

      merci du retour . Je le ferai peut être dans un autre article. Le but à moitié caché ici est principalement de montrer que plus on découple, moins le fossé est grand pour la migration. Néanmoins il est vrai que pour migrer totalement ( notamment ce qui est template ) il y a un travail de réécriture à faire.

So, what do you think ?