Quelques grands principes pour aller vers Angular 2.x en venant d’Angular 1.4 ?

Le monde IT est en plein bouleversement et coté Front ce n’est pas toujours évident de gérer l’obsolescence, j’ai récemment du proposer de transformer un projet construit autour d’Angular 1.4  vers de l’Angular 2.3 …

Le plus dur est la plus part du temps de comprendre la question … alors Angular 1.4 vers Angular 2.3, c’est un palier technique ou une transformation ?

Un peu d’histoire

Le World Wide Web est un système de documentation hypertexte créé en 1993 pour les besoins du Centre européen pour la recherche nucléaire (CERN). Le premier navigateur Web (NCSA Mosaic) a été créé la même année par le National Center for Supercomputing Applications (NCSA).

Le World Wide Web a permis aux utilisateurs de se partager des documents et des images plus rapidement que via le courrier électronique et plus facilement que via le partage de fichiers.

Le nombre grandissant de documents publiés a rendu rapidement les moteurs de recherche nécessaires pour les retrouver : l’utilisateur entre un mot clé, le serveur Web effectue la recherche, puis envoie le résultat sous forme d’un document.

Les moteurs de recherche ont été mis en œuvre par extension du serveur Web.

En 1995, le NCSA publie la norme industrielle CGI, qui spécifie quelles sont les modalités d’extension d’un serveur Web, dans le but de le brancher avec un logiciel applicatif – par exemple un moteur de recherche.

La technologie des applications Web a évolué très rapidement entre 1994 et 2000, où plusieurs logiciels de serveurs Web réservés à cet usage sont sortis sur le marché un après l’autre, ainsi que des améliorations des navigateurs Web.

Les premières applications Web souffraient d’une maniabilité et d’une ergonomie inférieure aux applications client. Est appelée Rich Internet Application une application Web qui offre une maniabilité et une ergonomie équivalente à une application client. Le terme Rich Internet Application est apparu la première fois dans une publication de Macromedia en 2002.

Figure 1 : historique des applications WEB

 

Une étape majeure est franchie à partir des années 2010 avec le déploiement des applications dites « Web 2.0 » : GWT, React, AngularJS … et finalement Angular 2 en septembre 2016 …

Angular d’abord,  web 2.0 puis 3.0 … il s’adapte, mais surtout il est désormais supporté par un acteur de poids !

AngularJS 1.x ou AngularJS … c’est quoi ?

AngularJS est un Framework web s’exécutant dans le navigateur du client final, prenant le contrôle et pouvant donc modifier directement le DOM (Cf. http://www.w3schools.com/js/js_htmldom.asp) du navigateur. Ce Framework est un Framework JavaScript.

Quand une page Web est chargée, le navigateur crée un modèle objet de la page (DOM).

Avec ce modèle objet, le JavaScript est entièrement activé pour créer un HTML dynamique:

  • Le JavaScript peut ajouter, modifier et supprimer tous les éléments et attributs HTML dans la page,
  • Le JavaScript peut changer tous les styles CSS dans la page,
  • Le JavaScript peut réagir à tous les événements existants dans la page,
  • Le JavaScript peut créer de nouveaux événements dans la page.

Figure 2 : fonctionnement du Framework AngularJS

Figure 3 : structuration du DOM du navigateur

 

La vue principale de la page HTML déclare l’application AngularJS.

L’application AngularJS contient l’ensemble des modules nécessaires à l’application :

  • Les vues,
  • Les directives / Les filtres,
  • Les contrôleurs,
  • Les modèles,
  • Les services,
  • Les scopes.

On parle d’application “single page” dans le sens ou c’est cette unique page HTML qui permet de démarrer l’application Angular, plus aucune autre page complète ne sera demandée par la suite. Seulement des fragments HTML pourront être chargés pour modifier dynamiquement des parties du DOM.

Le principe fondamental d’une application AngularJS est que la « connaissance » des instances (modèle, vue …) est unidirectionnelle. De ce fait, la vue connait son contrôleur qui connait un ou des modèle(s) qui connaissent les services.

Le fait d’avoir des couches modulaires permet ainsi de tester unitairement chaque couche métier de manière indépendante, mais aussi d’avoir un développement coupé par responsabilité (couche vue, couche métier, …), facilitant ainsi la maintenance et le « bug tracking ».

Les vues

Chaque vue fonctionne de pair avec un contrôleur. La vue consomme les données en data-binding et appelle les méthodes du contrôleur. Elle peut également inclure des directives et faire appel aux filtres déclarés dans l’application.

Les directives et Les filtres

Les directives sont des add-on au HTML. Une directive est un composant qui peut déclarer ou non son propre scope / contrôleur.

Les filtres sont des méthodes permettant la transformation de la donnée : filtre d’un tableau, formatage d’une date, d’un nombre, …
Les filtres peuvent être utilisés directement dans le code HTML ou via le JavaScript.

Les contrôleurs

Le contrôleur contient un ou plusieurs modèles de donnée. Il contient des méthodes propres à la vue ainsi que des variables d’état ou d’affichage. Il sert également de proxy au model.

Les modèles

Les modèles sont dédiés à un type de donnée.

Ils contiennent la donnée et toutes les méthodes de manipulation de cette dernière :

  • Appels de services,
  • Ajout,
  • Sélection.

Les modèles font appel aux services en cas de besoin de communication serveur.

Lors du retour de l’appel de service, le modèle s’appuie sur le bus évènementiel ($rootScope) d’AngularJS pour notifier les changements. Le but de passer par le bus évènementiel est d’éviter toute dépendance du modèle envers les vues qui l’utilisent.

Le scope ($scope et $rootScope)

Les scopes d’AngularJS sont des objets qui servent de contexte d’évaluation des expressions contenues dans les templates, ils sont le plus souvent manipulés dans la page ou dans les contrôleurs.

Ils forment un arbre, dont la racine est le seul scope de l’application qui est aussi publié comme un service, sous le nom $rootScope. Ce $rootScope est associé à l’élément contenant toute l’application AngularJS, celui sur lequel on met la directive ngApp : ça peut être l’élément <html> lui-même, ou le <body>, ou un <div> à l’intérieur, ou tout autre éléments de la page.

Figure 4 : arbre des scopes

La structure arborescente des scopes est calquée sur celle des éléments de la page HTML. Chaque scope est lié à un élément du DOM, mais la réciproque n’est pas vraie. Il n’y a pas un scope pour chaque élément, seulement pour certains des éléments de la page HTML, parce qu’on a placé sur ces éléments une directive AngularJS qui crée un nouveau scope. C’est le cas des directives ngController, ngView, ngRepeat, etc.

Quand une directive crée un scope sur un élément HTML, ce scope aura pour parent le premier scope rencontré en remontant les éléments HTML.

Pour simplifier la manipulation des scopes il existe dans AngularJS des systèmes d’audit et de détection de notification $watch ou encore $broadcast. Ces éléments du Framework permettent de réagir à la modification d’une variable dans un scope par exemple.

Les services

Les services sont des classes :

  • Ils peuvent être statiques (couche métier le plus souvent),
  • Ils peuvent être dynamiques (consommant les API REST du back-office par exemple).

Angular 2.x c’est juste un palier technique ?

Non, Angular 2 est entièrement disponible en TypeScript et répond à la spécification ECMAScript 6 (TypeScript est une extension de la norme ES6). Angular 2 n’est pas une mise à jour mais une réécriture complète.

L’orientation Angular 2 est une orientation « Mobile » contrairement à AngularJS 1.x et intègre les bonnes pratiques du marché :

  • RxJS (pour reactive JS),
  • TypeScript (lancé par Microsoft à l’origine).

Un changement fondamental est la suppression de la notion du $scope permettant en AngularJS 1.0 de lier les vues et les contrôleurs (qui eux même disparaissent au profit de composants). Ce changement majeur est la source majeure de « rework » d’une application AngularJS 1.0 en Angular 2 (Cf. http://www.technicaldiary.com/difference-angular-1-vs-angular-2 ), il permet de construire des applications plus performantes.

Le langage TypeScript est un langage orienté objet proposé par Microsoft et permet de retrouver coté Front une logique métier très proche de la logique du BackEnd.

Les autres axes de transformation sont aussi :

  • Une philosophie exclusivement basée sur la notion de composant avec une gestion de détection de changement sous forme d’arbre (pour des raisons de performance),
  • Une révision complète de la logique d’injection de composant et de l’import (pour des raisons de performances),
  • Une révision complète de la gestion de la navigation dans l’application (NgRoute),
  • Un groupe AngularJS 1 HTML/CSS/Directive/Controller devient un composant Angular 2 (Cf. comparaison de la structure d’une application Angular ci-dessous).

Figure 5 : comparaison de la structure AngularJS et Angular 2

 

Un autre axe important de changement, est la révision complète des méthodes de détection de changement, en particulier, les méthodes de notification (broadcast) et de monitoring (watch) des changements apportés au modèle sont radicalement différentes en Angular 2 toujours dans une optique de performance.

Figure 6 : gestion de la détection des changements

 

Les composants

En Angular 2, tout est composant (Cf. https://Angular 2/docs/ts/latest/api/core/index/Component-decorator.html), c’est le seul élément que l’on peut présenter sur une page (les directives n’ont plus de vue en Angular2), il contient :

  • Le « template » de présentation (HTML + CSS),
  • Les « services » injectés directement sur le composant,
  • Le code du composant et la logique de gestion des données.

Les services

Un service est le mécanisme utilisé pour partager des fonctionnalités sur des composants : c’est la mécanique de base préconisée sur Angular 2 pour mutualiser des comportements applicatifs (les services de niveau $scope ne sont plus possible). Il n’y a pas de nouveauté par rapport à Angular 1.4 si ce n’est :

  • Une écriture légèrement différente,
  • Une mécanique d’injection revue et plus performante.

Les modèles

C’est la grande nouveauté sur Framework Angular 2 (portée par l’utilisation du TypeScript), il est désormais possible de typer les données manipulées par les composants et les services. À mesure qu’une application croit en taille, il devient important qu’elles soient bien organisées avec une structure typée en place.

Quels sont les apports d’Angular 2 par rapport à la première version ?

Les risques portés par ce nouveau Framework sont des risques liés à la rapidité des changements dans le monde du Web 3.0 :

  • Un risque de perte d’efficacité,
  • Le Framework Angular 2 pousse à utiliser un nouveau langage typé : le TypeScript,
  • Plus qu’une migration, on parle de transformation, il faut restructurer le code existant,
  • Un risque sur la pérennité du Framework lui-même,
  • Le Framework Angular 2 est une réécriture complète : s’il ne prend pas, Google peut arrêter brutalement son support (Cf. expérience GWT) Un risque de régression des performances de l’application migrée en Angular 2,
  • Les impacts sur un code AngularJS 1 sont importants (Cf. différence entre les 2 Framework) – ce risque est lié également à la perte d’efficacité possible,
  • Les projets digitaux sont largement impactés par les sujets de performance de l’expérience utilisateur, changer de Framework c’est ouvrir le risque d’avoir de nouveaux problèmes de performance,
  • Un risque de perte de compatibilité avec le monde mobile,
  • L’axe « multi-devices » est un axe fort des projets Web 3.0 changer de Framework pourrait faire régresser ce point.

La stratégie de ce nouveau Framework est d’adresser plusieurs apports fondamentaux pour couvrir ces risques :

  • L’efficacité intrinsèque du Framework pour assurer la qualité et la pérennité du code produit dans le temps,
  • Suivre les standards du Web 3.0 et prendre les bonnes pratiques d’acteurs existants pour assurer la pérennité du Framework,
  • Augmenter les performances du Framework pour améliorer l’expérience utilisateur,
  • S’adapter aux problématiques mobiles pour toujours améliorer l’expérience utilisateur et suivre les tendances du marché (saisies multi-devices par exemple).

Efficacité

Le socle technologique AngularJS 1 est basé sur JavaScript (ES5 6) et le Framework Angular 2 impose d’évoluer vers TypeScript et la notion de composant : le risque de non-retour sur investissement est important, il faut réapprendre un nouveau langage ?

Oui, parce que la version 2.0 de ce Framework pousse vers TypeScript naturellement du fait de l’association de Google avec un autre partenaire important du marché : Microsoft. Mais cette dynamique de changement en revanche est très vertueuse du point de vue du génie logiciel dans la mesure où les développeurs gagneront un typage fort et un code plus maintenable (avec le support de l’injection de dépendances) : in fine, l’application sera développée plus rapidement et sera plus maintenable.

À noter que le TypeScript est une extension du JavaScript, ce qui permet de relativiser les changements provoqués par le passage en Angular 2 : on reste dans la même philosophie.

Concernant l’orientation composant du Framework Angular 2 : la limitation du couplage apportée par cette notion est une pratique qui apporte 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. En cas de migration, la quantité de code à réécrire sera diminuée.

Par ailleurs les équipes Angular 2 poussent à prendre les bonnes pratiques existantes sur les autres Framework ou d’autres projets Web 3.0. La problématique du « build » et du « test » sont des sujets naturellement adressés par les équipes travaillant sur le Framework Angular 2. « Angular-cli » par exemple, est un projet parallèle visant à industrialiser le « build » et structurant la méthode de production (https://github.com/angular/angular-cli).

L’éditeur le plus souvent recommandé de fait (en suivant les bonnes pratiques de la communauté) est l’éditeur VSCode : https://code.visualstudio.com.

Pérennité

L’architecture du Framework a évolué, et il faut réinvestir dans un apprentissage long et coûteux : le risque de non-retour sur investissement est important, il faut réapprendre un nouveau Framework ?

Oui, et pour une bonne raison : le Framework évolue effectivement mais pour suivre l’évolution du web 3.0 et du marché en général. On citera en particulier l’orientation Web Components (http://webcomponents.org) mais pas seulement. Les principes de consommation d’API « BackEnd » métiers basées sur le REST sont largement recommandés dans les architectures Angular et restent vrais pour la version 2.

Angular 2 supprime la notion de contrôleur telle qu’on la connait actuellement, pour la remplacer par des composants. C’est une approche plus moderne et pérenne, puisque de nombreuses librairies ont déjà franchies le pas comme Backbones ou React. La notion de MVC n’est plus tellement d’actualité dans le développement d’interfaces, où l’on privilégie désormais une approche composants.

La courbe d’apprentissage Angular 2 a l’avantage d’être unique et universelle : contrairement à la version 1 du Framework avec laquelle chaque développeur utilisait les parties selon son bon vouloir pour développer, la version Angular 2 portée par Google arrive avec un guide architectural fort (https://angular.io).

Un point fort du Framework Angular en général et dans sa version 2 en particulier est de promouvoir l’utilisation des principes REST pour la consommation des API métier en BackEnd (lui-même dans certains cas en JavaScript avec nodejs) et de reprendre les principes d’une gestion managée des données (store ou entrepôt de données).

En se basant sur des technologies telles que le « ShadowDom »,  « Observables » et d’autres nouveautés apportées par ES2015 ce Framework s’adapte naturellement aux nouveaux standards du Web. Angular 2 s’intègre par ailleurs parfaitement bien avec les composants construits via d’autres bibliothèques (Polymer, X-Tag, etc.).

Performance

L’architecture du Framework a évoluée : le risque de problématique de performance peut être présent avec un Framework en sortie de release de septembre 2016 ?

Non, le traitement du sujet de la performance est un sujet initiateur de la volonté de réécrire le Framework dès les débuts de 2015, c’est d’ailleurs un des immenses gains attendus par cette nouvelle version. L’un des plus grands reproches qui aient été faits à AngularJS 1 sont ses lacunes en termes de performance : pour pallier à ce problème, les développeurs d’Angular ont décidé de se reposer davantage sur les briques natives du navigateur, et revoir la stratégie de détection des changements.

Actuellement, lorsqu’on utilise le data-binding d’AngularJS 1, 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 appelle le  « dirty-checking » : le problème de cette méthode est que la performance se dégrade exponentiellement aux nombre d’objets que l’on observe.

Avec Angular 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 et propage l’information aux composants parents. De cette manière, la détection n’a pas d’impact sur l’ensemble de l’application et les dégradations de performances sont linéaires.

Mobilité

L’architecture du Framework a évolué : l’adaptation aux terminaux mobiles est-elle prise en compte ?
Oui, gardons à l’esprit que c’est Google qui est aux commandes sur ce projet, en association avec des partenaires forts comme Microsoft. Google n’est pas uniquement une société capable de miracles technologiques, mais aussi un visionnaire de ce que sera le web de demain, et l’acteur qui pèse le plus pour imposer les normes technologiques : la cible terminaux mobiles n’a pas été oubliée.

La conception modulaire du Framework Angular 2 permet de réduire considérablement son empreinte mémoire sur les terminaux mobiles. Par ailleurs, il s’intègre naturellement avec les composants de « Material Design », ce qui permet la création d’applications dites « responsive » et multiplateformes (téléphone, tablettes, ordinateur de bureau).

À noter que des Framework « material-design » Angular 2 sont déjà proposés : https://material.angular.io et poussé par Google lui-même.

Comment migrer une application Angular 1.x vers Angular 2 ?

Premier constat, il n’y a pas de moyen automatique pour migrer une application 1.x vers Angular 2. Il n’y a pas non plus de mécanisme de migration outillée, cette migration est faite par les équipes de développement : on parlera d’ailleurs plutôt de transformation.

Le choix entre deux scénario

L’équipe Angular 2 indique qu’il y a deux stratégies pour faire migrer une application 1.x vers le 2.0 :

  • L’approche « Big Bang » ou « One Shot »,
  • L’approche « Incrémentale ».

Le « One Shot »

Le choix de cette stratégie implique un arrêt complet des développements en cours, et de migrer l’application entière en Angular 2.
Le plus grand avantage d’une transformation « one shot » :

  • C’est le moyen le plus rapide pour transformer l’application en Angular 2. Cela signifie que l’on utilise les nouvelles fonctionnalités telles que les composants, le TypeScript et la nouvelle syntaxe de « templating » le plus tôt possible,
  • La dette technique est annulée rapidement.

A l’opposé, cette approche à plusieurs désavantages :

  • Accepter cette période de gel du produit,
  • Plus l’application est importante en taille plus le Big Bang est long en temps,
  • Il faut attendre la convergence des Framework 1.x utilisé dans l’application à migrer (UiRouter, Restangular …),
  • Ce type d’approche génère un effet tunnel important,
  • Visibilité sur le planning d’avancement difficile,
  • Gestion des alertes complexes,
  • Difficulté de gestion « agile » des feedbacks externes.

La démarche incrémentale

La démarche incrémentale est un axe de transformation dans lequel on met à jour les parties de l’application avec du code Angular 2, en gardant des parties de code AngularJS 1.x. Ceci est possible parce que l’on peut exécuter Angular 2 et AngularJS 1.x dans une même application (avec des contraintes détaillées plus loin).

L’approche est possible suivant 2 axes :

  • Une application Angular 2 qui héberge une application AngularJS 1.x,
  • Inversement, une application 1.x qui héberge des composants 2.0.

Par exemple on peut choisir de migrer tous les « contrôleurs » existants en services Angular 2, et garder certaines directives sous AngularJS 1.4. Un autre exemple est de rester en AngularJS 1.4 pour les contrôleurs et les services, mais écrire nos nouvelles directives avec les composants Angular 2.

L’avantage de l’incrémental est que cela permet beaucoup de flexibilité dans la façon de transformer l’application en Angular 2. Mais tout comme l’approche Big Bang, l’incrémental a aussi quelques inconvénients :

  • Le premier est que la cohabitation des 2 Framework implique que le navigateur devra télécharger deux Framework complets, et devra les analyser, cela aura un impact sur l’expérience utilisateur (performances dégradées),
  • Le second est que d’avoir deux Framework avec deux philosophies très différentes, va rendre le code difficilement maintenable : un code hybride étrange coincé entre deux mondes et in fine une transformation complète Angular 2 sera nécessaire.

La démarche incrémentale VS le Big Bang

« One Shot » Incrémentale
Petite application Grande application
Peu de dépendance Beaucoup de dépendances
Pas de problématique de planning Planning complexe

 

Fondamentalement, la matrice indique que plus l’application n’est petite, alors plus le « Big Bang » est logique. En effet, le temps qu’il faut pour effectuer un Big Bang est directement lié à la taille de l’application.

Une autre facette de la décision est le nombre de dépendances dans l’application. Comme indiqué plus haut, on ne peut mettre à niveau vers Angular 2 complètement que lorsque toutes les dépendances sont elles-mêmes migrées. Dans la plupart des librairies utilisées sur les projets sont dans des statuts béta coté Angular 2 … en 2016 … on pourrait se reposer la question aujourd’hui.

Préparation de la transformation en Angular 2

Dans tous les cas de figure une étape préparatoire à la transformation en TypeScript Angular 2 est nécessaire. Cette activité sera incluse dans la transformation globale.

Porté des contrôleurs

Un changement majeur apporté par Angular 2 est l’arrêt de l’utilisation du $scope. En effet le scope devient la portée de l’instance du composant. Une première action est d’utiliser la notation « controllerAS » dans le code existant pour supprimer tout ajout de l’utilisation du $scope dans le code existant.

Migration 1.5 aussitôt que possible

L’objectif de la version 1.5 d’AngularJS est de permettre un passage plus simple à Angular 2. Une transformation en AngularJS 1.5 peut être un point de passage temporaire permettant d’étaler la mise en place de la stratégie de transformation en Angular 2.

Utilisation de l’ES6 aussitôt que possible

Avec l’utilisation d’un « transpiler » tel que Babel ou encore TypeScript il est possible d’écrire en ES6 aujourd’hui. Un « transpiler » transforme le code ES6 au code ES5, de sorte que l’application fonctionnera toujours dans tous les navigateurs.

Le plus grand avantage de ES6 est de permettre d’écrire des “classes” et Angular 2 est fortement basé sur ce principe : les composants sont des classes par exemple. En utilisant des classes pour définir des services et des contrôleurs de directive le travail de transformation est déjà lancé.

Le plus grand avantage de ES6 est de permettre d’écrire des “classes” et Angular 2 est fortement basé sur ce principe : les composants sont des classes par exemple. En utilisant des classes pour définir des services et des contrôleurs de directive le travail de transformation est déjà lancé.

Pour le choix Babel vs TypeScript :

  • Si l’objectif est de construire de grosses applications et de travailler sur la maintenabilité et l’industrialisation : TypeScript est la solution,
  • Si l’objectif est de travailler avec les dernières nouveautés ES6 : Babel est la solution.

Dans notre cas, INDIGO le choix TypeScript, est raisonnable et permet une construction applicative maintenable et très connectée au back office (utilisation des mêmes modèles de données de part et d’autre par exemple).

Utilisation du système de routage Angular 2

Le router Angular 2 est porté en AngularJS 1.5 aussi il peut être intéressant d’utiliser ce routeur en 1.5 pour économiser une migration. Le routeur dans sa nouvelle mouture embarque des modifications importantes en prenant en compte des feedback sur la première version.

En synthèse comment migrer vers Angular 2.x depuis la version Angular 1.4 ?

À la vue des différences entre les 2 Framework on constate que l’on ne peut pas parler d’une simple migration, on est plus proche d’une transformation :

  • Soit en mode « one shot »,
  • Soit en mode incrémental.

Les différences entre les 2 Framework sont notables :

  • Approche « composants » centrique à l’inverse d’AngularJS qui est une approche plus HTML/DOM,
  • Changement du langage de programmation,
  • TypeScript (extension du JavaScript) est largement recommandé pour ses apports (productivité, lisibilité),
  • Le code TypeScript est une extension plus fortement typée et orientée objet proposé initialement par Microsoft.

 

Nous savons aussi que nous pouvons préparer cette transformation en utilisant un “transpiler” tel que Babel pour commencer à utiliser les classes ES6 et migrer en AngularJS 1.5 pour faciliter la migration en 2.0.

La branche AngularJS 1.x est n’est plus supportée fin 2017 (*), mais elle est toujours activement maintenue, et la communauté est toujours aussi active. Ainsi une transformation en Angular 2 reculée au plus tard peut rester une stratégie valable.

Note (*) : La fin de support officiel Google de AngularJS fin 2017 (bugfix + security) et Angular 2 est sortie le 14/09/216.

Néanmoins Google propose ce nouveau Framework :

  • Pour du gain de performance de l’exécution dans le navigateur (rapport de 1 à 5) par rapport à AngularJS,
  • Pour une amélioration de la maintenance du patrimoine de source (TypeScript) et sa réutilisabilité plus forte qu’AngularJS,
  • Pour un support « fort » des standards Web et son orientation Mobile (pour cibler les « Progressive Apps »),
  • Des partenariats avec des acteurs importants du marché : Microsoft avec le TypeScript.

Bibliographie

Référence Document Référence
Ref1 UiRouter vs NgRouter https://www.youtube.com/watch?v=pai1ZdFI2dg
Ref2 NgRouter https://medium.com/angularjs-meetup-south-london/angular-just-another-introduction-to-ngnewrouter-vs-ui-router-72bfcb228017#.34knkfc5c
Ref3 RxJS JavaScript https://github.com/Reactive-Extensions/RxJS
Ref4 Composants Angular2 https://angular-2-training-book.rangle.io/handout/components/
Ref5 Description du DOM http://www.w3schools.com/js/js_htmldom.asp
Ref6 Différence majeures entre les deux Framework http://www.technicaldiary.com/difference-angular-1-vs-angular-2/

 

Ref7 Composants Angular2 https://Angular 2/docs/ts/latest/api/core/index/Component-decorator.html
Ref8 Upgrade https://Angular 2/docs/ts/latest/guide/upgrade.html
Ref9 Misc https://thinkster.io/a-better-way-to-learn-angularjs
Ref11 Gestion du $scope AngularJS http://www.frangular.com/2013/10/scope-isole-dans-les-directives.html
Ref13 La marque Angular http://angularjs.blogspot.sk/2016/12/ok-let-me-explain-its-going-to-be.html
Ref14 JavaScript et Immutabilité http://blog.scottlogic.com/2016/01/05/angular2-with-immutablejs.html
Ref15 Révision du fonctionnement des formulaires http://blog.thoughtram.io/angular/2016/06/22/model-driven-forms-in-angular-2.html

 

Ref16 Store http://onehungrymind.com/build-better-angular-2-application-redux-ngrx/
Ref17 Store https://gist.github.com/btroncone/a6e4347326749f938510