Angular v16 est arrivé (Signaux et Wsshh! Sons)

Découvrez tous les points forts inclus dans Angular 16.

Ouais, je sais que je t’ai eu avec le titre, non ? Si vous vous demandez encore de quoi parle le buzz, tout d’abord, la plus grande version depuis le déploiement initial d’Angular (citant Minko Gechev dans l’étonnant article de blog de la version officielle d’Angular) s’est produit, puis c’est arrivé le 3 mai. Ce qui est si proche du 4 mai (comme dans Que le quatrième soit avec vous), d’où les sons émis lors du découpage de l’air en tenant une lame chargée de cristal Kyber.

En dépit d’être un fan de Star Wars, je ne vais pas spéculer sur la façon exacte dont on devrait épeler le son d’un sabre laser. Au lieu de cela, je vais me concentrer sur les nombreux faits saillants intéressants de la version Angular 16, puis passer en revue le concept de signaux le plus en vogue actuel. Bien que ceux ci-dessous ne comprennent pas la liste complète des fonctionnalités et améliorations, ça vaut le coup de commencer:

• Nouvelles primitives de réactivité—Entrez signaux premier aperçu du développeur
• Non destructif hydratation aperçu du développeur
• Le nouveau constructeur de CLI sur esbuild
• Importation automatique des composants et des canaux du service de langage Angular
• Prise en charge des décorateurs Typescript 5.0 et ECMAScript
• Nouveaux schémas autonomes, schémas de migration et guide de migration autonome

De plus, je ne peux pas sauter le facilité de vie apportée à tous ceux qui mettent la main sur Angular avec l’introduction de :

• Marquer les entrées de composant et de directive comme requis
• Transmettre les données de routage, les paramètres de chemin et de requête aux entrées d’un composant de routage
• Injectables OnDestroy
• Balises de composants à fermeture automatique

Sur le sécurité et accessibilité devant l’équipe angulaire continue de s’améliorer et de se développer :

• Prise en charge CSP des styles en ligne (également dans la CLI) avec le nonce spécification d’attribut
• Accessibilité des composants angulaires (vérifiez ce qui est fermé jusqu’à présent ici)

Avant de plonger en profondeur

Après avoir lu tous les trucs sympas avec Angular 16, je parie que vous essayez de mettre à jour votre application dès que possible, mais c’est d’abord l’heure de la lecture (et croyez-moi, c’est toujours pour le mieux).

Terminez les journaux des modifications sur :

Changements notables tels que :

• Prise en charge de Node.js 14 supprimée ; Node.js v16 ou v18 requis
• Prise en charge de TypeScript 4.8 supprimée ; Typescript version 4.9 ou ultérieure est requis
• Compilateur de compatibilité angulaire (ngcc) supprimé
• ReflectiveInjector et les symboles associés supprimés
• Format de paquet angulaire sorties aplaties ESM 2015 (FESM2015) supprimées
• Sorties EcmaScript 2020 mises à jour vers EcmaScript 2022 (y compris la sortie aplatie)
• Router.createUrlTree mis à jour—attention si vous vous moquez ActivatedRoute

Donc, je suppose que c’est la seule chose qui se dresse entre vous et la nouvelle version de votre application Angular, en plus de quelques lectures, refactorisations, tests unitaires et de régression, débogage puis lecture et codage à nouveau, mais c’est la beauté après tout . Mis à part le plaisir, comme pour toutes les fonctionnalités nouvelles et expérimentales, la prudence s’impose d’abord, alors mieux vaut prévenir que guérir.

Jusqu’à ce moment, tout indique qu’Angular 16 changerait le jeu ou la vie (ou les deux). Ainsi, je mettrais personnellement à jour toutes mes applications Kendo UI pour Angular que j’utilise dans mon travail quotidien, progressivement et un module à la fois. Je sais que Kendo Angular est livré avec un support dès le premier jour pour chaque version de framework notable, donc tout est entre mes mains maintenant. Et ce faisant, je serais plus qu’heureux de vous informer et de bloguer sur ou même de provoquer et d’inspirer mon incroyable et amusant collègue
Alyssa Nicol pour le faire.

En fait, j’ai rapidement joué avec l’hydratation non destructive

Jusqu’à maintenant avec rendu côté serveur dans Angular, le DOM de l’application a été complètement détruit lors du démarrage du client. Cela signifiait un scintillement après le rendu de la page et avant l’interaction avec celle-ci. Plus de solutions de contournement pour cela ou d’impact négatif sur les CLS et LCP Core Web Vitals ; comme avec Angular 16, le serveur rend l’application et lorsque le client est démarré, il réutilise les structures DOM existantes. Par conséquent, il n’est pas nécessaire de tous les détruire. De plus, les requêtes effectuées sur le serveur sont mises en cache, donc la récupération des mêmes données sur le client n’est plus une chose maintenant.

A en juger par le Feuille de route angulaire 2023, les améliorations du rendu côté serveur représentent un effort considérable. Ce qui est formidable pour moi, car mes applications entièrement natives qui utilisent Angular Universal et sont construites avec Kendo UI pour Angular les obtiendront directement. J’avais hâte de jouer avec une application Kendo Node.js en suivant l’officiel guide par l’équipe angulaire :

Mise à jour (en gras dessous) app.module.ts déposer:

import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core'; 
import { RouterModule } from '@angular/router'; 
import {provideClientHydration} from '@angular/platform-browser'; 
import { AppComponent } from './app.component'; 
import { HomeComponent } from './home/home.component'; 
import { TransferHttpCacheModule } from '@nguniversal/common'; 
import { GridModule } from '@progress/kendo-angular-grid'; 
import { BrowserAnimationsModule } from '@angular/platform-browser/animations'; 
@NgModule({ 
declarations: [ 
AppComponent, 
HomeComponent, 
], 
imports: [ 
BrowserAnimationsModule, 
BrowserModule.withServerTransition({ appId: 'serverApp' }), 
RouterModule.forRoot([ 
{ path: '', component: HomeComponent, pathMatch: 'full' }, 
{ path: 'lazy', loadChildren: () => import('./lazy/lazy.module').then(m => m.LazyModule) }, 
{ path: 'lazy/nested', loadChildren: () => import('./lazy/lazy.module').then(m => m.LazyModule) } 
]), 
TransferHttpCacheModule, 
GridModule 
], 
providers: [ provideClientHydration() ], 
bootstrap: [AppComponent] 
}) 
export class AppModule { } 

Note qu’avec l’hydratation, il est indispensable d’avoir des structures DOM identiques sur le serveur et le client, alors incluez provideClientHydration() dans les fournisseurs respectifs lors de l’amorçage sur le serveur. Toute incompatibilité entraînerait des erreurs, qu’elles soient causées par une structure HTML non valide ou par une manipulation directe du DOM avec les API du navigateur. Vous souhaitez omettre l’hydratation d’un composant et de son arborescence en utilisant ngSkipHydration dans ce cas:

@Component({ 

  ... 

 host: {ngSkipHydration: 'true'}, 

}) 

Et c’est tout. Je ne spéculerais certainement pas encore sur la question de savoir si mon application serait maintenant plus rapide qu’un guépard sur des rollers, car jouer avec de nouvelles fonctionnalités sur l’environnement de développement est cool, mais les appliquer dès le début de la production est une toute autre histoire.

La partie 2 de cet article de blog serait une nouvelle fonctionnalité de signal expliquée – de manière simple !

C’est quelque chose que j’aime faire à chaque occasion car je pense que le temps passé à comprendre de nouvelles choses, même s’il faut commencer par AB, rapporte beaucoup dans le temps. Ou on pourrait dire, investissez plus de temps pour gagner encore plus de temps (sans jeu de mots).

Quelle est l’histoire autour des signaux ?

Essentiellement, un signal est un type distinctif de variable qui stocke une valeur, avec l’avantage supplémentaire de fournir des alertes (c’est-à-dire, notifier tous les nœuds dépendants), lorsque la valeur de la variable est modifiée.

Ou je peux vous référer à l’équipe angulaire définition—Un signal est une valeur avec une sémantique de changement explicite, représentée par une fonction getter à argument nul renvoyant la valeur actuelle du signal:

interface Signal<T> { 

  (): T; 

  [SIGNAL]: unknown; 

} 

Ou je peux vous renvoyer au commentaire d’Alex Rickabaugh—Un signal est une source de valeur.

Il s’agit de la gestion de l’état et de l’introduction d’une approche plus légère et flexible pour la détection des changements (et plus précisément, la détection par composant). Les signaux peuvent être inscriptibles ou calculés. Les premiers obtiennent leurs valeurs mises à jour par l’API de mutation. Ces derniers sont en lecture seule et tirent leurs valeurs d’autres signaux. Vous pouvez les utiliser dans des composants, des modèles, des services, des directives et ainsi de suite.

Bien qu’il ait déjà été utilisé dans certaines autres bibliothèques, l’adoption de ce mécanisme réactif par Angular positionne déjà les signaux comme un coupable majeur pour un changeur de jeu slash innovant, le remplacement de RxJS, Zone.js ou une raison de repenser les meilleures pratiques NgRX. Mais pour le moment, les signaux restent une option, vous n’avez donc rien à changer si vous n’êtes pas prêt à le faire.

J’ai décidé de jouer (je veux vraiment dire jouer, vous pouvez en juger par les noms d’éléments pas si créatifs) avec des signaux dans un Grille angulaire de Kendo. La mise à jour vers Angular 16 a pris en charge toutes les importations nécessaires ; Je viens de l’ajouter afin de l’utiliser pour la grille.

 import { Component, signal } from '@angular/core'; 

Voici comment app.components.ts fichier ressemble:

import { Component, signal } from '@angular/core'; 



@Component({ 

  selector: 'app-root', 

  templateUrl: './app.component.html', 

  styleUrls: ['./app.component.css'], 

}) 

export class AppComponent { 

  public gridData = signal([ 

    { 

      ProductID: 1, 

      ProductName: 'Chai', 

      UnitPrice: 18, 

      Category: { 

        CategoryID: 1, 

        CategoryName: 'Beverages', 

      }, 

    }, 

    { 

      ProductID: 2, 

      ProductName: 'Chang', 

      UnitPrice: 19, 

      Category: { 

        CategoryID: 1, 

        CategoryName: 'Beverages', 

      }, 

    }, 

  ]); 

  public categories: Category[] = [ 

    { CategoryID: 1, CategoryName: 'Beverages' }, 

    { CategoryID: 2, CategoryName: 'Condiments' }, 

    { CategoryID: 3, CategoryName: 'Confections' }, 

    { CategoryID: 4, CategoryName: 'Dairy Products' }, 

    { CategoryID: 5, CategoryName: 'Grains/Cereals' }, 

    { CategoryID: 6, CategoryName: 'Meat/Poultry' }, 

    { CategoryID: 7, CategoryName: 'Produce' }, 

    { CategoryID: 8, CategoryName: 'Seafood' }, 

  ]; 

  public updateData() { 



    this.gridData.mutate((gridData) => { 

      gridData.push(this.generateRandomUser()); 

    }); 

  } 

  public getRandomItem<T>(array: T[]): T { 

    const index = Math.floor(Math.random() * array.length); 

    return array[index]; 

  } 

  public generateRandomUser(){ 

    const product: Product = { 

        ProductID: Math.floor(Math.random() * 500), 

        ProductName: 'Product ' + Math.floor(Math.random() * 100), 

        UnitPrice: Math.floor(Math.random() * 100), 

        Category: this.getRandomItem(this.categories), 

      }; 

      return product; 

  } 

} 

type Category = { 

    CategoryID: number; 

    CategoryName: string; 

  }; 



  type Product = { 

    ProductID: number; 

    ProductName: string; 

    UnitPrice: number; 

    Category: Category; 

  }; 

L’idée est d’appeler une fonction générant un objet aléatoire et de l’ajouter à la collection de la grille.

Avant signaux, nous avons dû changer la référence à la collection :

gridData.push(this.generateRandomUser()); 

this.gridData =[...this.gridData]; 

Ce qui a finalement déclenché la détection des changements dans l’ensemble de l’arborescence.

Après signaux, seule la grille est mise à jour et mutate() prend soin de changer l’interface utilisateur.

this.gridData.mutate((gridData) => { 

      gridData.push(this.generateRandomUser()); 

Voici à quoi ça ressemble :

Et c’est tout. Si vous souhaitez vous familiariser avec l’ensemble du concept de signaux dans Angular, je vous renvoie aux quatre parties RFC d’Angular :

Quelques mots sur les mises à jour CSP dans Angular 16

Alors que le sujet de la sécurité dans le développement Web moderne est un candidat digne d’un poste séparé ou d’une série de tels ou soyons honnêtes – un tome important, je voudrais féliciter l’équipe angulaire pour les dernières mises à jour sur le sujet.

Du point de vue de l’entreprise, les scripts en ligne ont toujours été une préoccupation lorsqu’ils pouvaient être marqués comme dangereux, d’où la Politique de sécurité du contenu (CSP) pour nier XSS (Cross Site Scripting). Angular 16 introduit un nonce attribut (disponible dans Framework, CLI, CDK, Material et Universal) qui vous permet de définir CSP pour les styles en ligne.

Le spécifier peut être fait parngCspNonceattribut sur la racine de l’application, ce qui est très avantageux si vous avez accès à des modèles côté serveur ou en utilisant l’attributCSP_NONCEjeton d’injection si vous avez accès au nonce lors de l’exécution.

Les gens comme moi qui utilisent l’interface utilisateur de Kendo dans les applications Angular bénéficieraient directement de cette fonctionnalité, poursuivant l’objectif d’être compatibles CSP et, en fin de compte, d’assurer une stricte conformité CSP. En plus de cela, la propre interface utilisateur Kendo 2023 pour Angular 2023 Roadmap inclut le remplacement de toutes les icônes de police utilisées en interne par des icônes SVG afin de répondre à la directive font-src et de détacher le CSS lié à la police des thèmes Kendo pour supprimer le besoin de la police -directive src.

Que la Force soit avec vous, et à la prochaine !