La version 4 d’Angular arrive à grands pas ! Comme indiqué dans ce ticket, il n’y a pas de version 3. Comme prévu, elle arrivera le 22 mars 2017. Enfin, presque comme prévu, car elle devait arriver le 15 mars. Comme il s’agit d’une version majeure, certains changements entrainent des ruptures de compatibilité. Passons en revue les évolutions significatives de cette version :

Passage a TypeScript 2.x

Si, lors de la sortie d’Angular 2.0, TypeScript 1.8 était suffisant, ce n’est plus le cas avec Angular 4.0. Une version 2.x est maintenant nécessaire; Vous pouvez consulter le blog de microsoft pour avoir un aperçu des nouveautés et ruptures de compatibilité induites par cette montée de version; Il permet notamment d’améliorer la vitesse de compilation de ngc.

AOT

Le compilateur AoT d’Angular produit beaucoup de code par template. Pour des projets d’envergure, cela peut devenir problématique, ou du moins, des questions peuvent se poser. Jusqu’à présent, l’équipe Angular n’en avait pas fait sa priorité car les performances à l’exécution étaient bonnes. Cependant, de nouveaux frameworks commencent à apparaître, prétendant avoir une performance similaire à Angular, avec une taille beaucoup plus réduite pour les modèles.

Des frameworks mieux qu’Angular ?? Cela ne semble pas avoir plu à la core team Angular et c’est tant mieux ! Ils ont donc repensé tout cela pour nouveau proposer un nouveau ViewEngine, le Renderer2.

Dans leur application de test, la taille du js générée est divisée par 3 pour un contenu non-gzippé en comparaison à une application utilisant le Closure Compiler de Google ! Par contre la détection de changement est 1,5x plus lente mais les performances sont quand même honorables et il est toujours possible de les améliorer à l’aide du onPush. Les animations ont dû bouger de package car il n’était plus possible de faire un tree shake dessus;

Excepté le changement d’endroit des sources des animations, il est a noté donc Renderer est maintenant déprécié en faveur du Renderer2 (qui ne possède plus la méthode invokeElementMethod() par ailleurs);

Sources : https://docs.google.com/document/d/195L4WaDSoI_kkW094LlShH6gT3B7K1GZpSBnnLkQR-g/preview#

Balise <template>

La balise <template> est maintenant dépréciée. Il y avait trop de confusion autour d’elle puisqu’il s’agit d’un véritable élément HTML; Il faut maintenant utiliser la balise <ng-template> qui est bien un component Angular.

*ngIf

La balise structurelle *ngIf supporte maintenant le else. Ainsi, il est possible d’afficher un autre template si la condition du test n’est pas remplie. Par exemple, un cas d’utilisation peut être ceci :

<ng-template #loading><div class= »loader »></div></ng-template> <div class= »container » *ngIf= »isValid ; else loading »> </div>

Il est également possible de déclarer une variable pour récupérer un observable comme ceci :

<ng-template #loading>Loading…</ng-template> <div *ngIf= »userObservable | async; else loading; let user »> {{ user.name }} </div>

Dépréciation de OpaqueToken

OpaqueToken est maintenant déprécié en faveur de InjectionToken<T>. Il est similaire à OpaqueToken (il en hérite) mais il permet maintenant de typer votre injection. Ainsi, sa récupération via injector.get() sera typée.

Support de « as » dans les templates

Il est maintenant possible d’utiliser as dans nos templates. Voici un exemple d’utilisation :

<div *ngFor= »var item of itemsStream |async as items”>Longueur : {{items.length}} </div>

Changement de comportement de certains services

Auparavant, tout provider déclarant la méthode ngOnDestroy() était instancié au plus tôt. Maintenant, seules les classes avec une annotation @Component, @Directive, @Pipe et@NgModule sont crées au plus tôt. Seuls les providers injectés directement ou transitivement dans un de ces composants sont instanciés au plus tôt.

Ajout de l’opaque token PLATFORM_ID

Grâce à lui, vous pourrez facilement connaître sur quel platform s’exécute votre code (browser, server, …). Voici comment l’utiliser :

… import {PLATFORM_ID} from « @angular/core »; import {isPlatformBrowser} from ‘@angular/common’; @Component({ selector: ‘monComponent’, templateUrl: ‘./item.component.html’, styleUrls: [‘./item.component.css’] }) export class MonComponent implements OnInit { constructor(@Inject(PLATFORM_ID) platformId: string) { console.log(isPlatformBrowser(platformId)); //true }

Form et novalidate

Par défaut, tous les formulaires utilisent maintenant l’attribut HTML5 novalidate qui permet de ne pas utiliser les validations HTML5. Une nouvelle directive est disponible pour réactiver la validation HTML5 : NgNativeValidate. Elle s’utilise comme ceci :

<form ngNativeValidate></form>

Modification du pipe Async

Si vous avez hérité du pipe Async dans un pipe custom, vous pourrez avoir un problème si vous avez surchargé la méthode transform. Elle attend maintenant un typage dans vos Observable, Promise, EventEmitter . any n’est plus accepté.

Ajout du pipe titlecase

Ce pipe permet de mettre la premiere lettre d’une chaîne de caractères en majuscule, puis le reste en miniscule.

Ajout du service MetaService

Ce service va vous permettre de « jouer » avec les métadonnées HTML afin d’en ajouter, d’en supprimer et simplement de pouvoir y accéder.

Simplification de la creation de URLSearchParams

Avant, lorsque nous ajoutions des paramètres à nos requêtes http, il fallait faire ceci :

const params= new URLSearchParams(); params.append(‘id’, ‘foo’); params.append(‘name’, ‘bar’); this.http.get(url, {params});

Maintenant, nous pouvons faire cela :

this.http.get(url, {params: {id: ‘foo’, name: ‘bar’}});

C’est quand même plus simple 😉

Amélioration du language-service

Beaucoup, beaucoup d’améliorations du module language-service qui permet un meilleur confort lorsque l’on code nos templates (auto complétion, …)

Dépréciation de ngOutletContext

Il faut maintenant utiliser ngTemplateOutletContext.

Voila pour les principales news à ce sujet ! Il n’y a donc pas de grosse rupture par rapport à la version 2 mais pas mal d’améliorations !