Angular v15—Elle est là !

Angular 15 apporte deux fonctionnalités étonnantes en avant-première pour les développeurs : les API autonomes (composants, canaux, directives) et la directive Image ! Regarde plus attentivement!

Joyeux automne, à ceux d’entre vous du même côté du globe que moi. Et BONNE VERSION ANGULAIRE 15 à tous !

Vérifiez version officielle Angular Blog Release écrit par la charmante Minko et les notes de version détaillées dans le CHANGELOG angulaire ou le plus facile à lire Changements avec rupture dans la doc ! Certains de mes points forts préférés sont deux fonctionnalités étonnantes de l’aperçu du développeur : les API autonomes (c’est-à-dire les composants, les canaux, les directives) et la directive Image !

Les mises à jour incluent, mais ne sont pas limitées à :

Mise à jour

La première chose est la première, cependant. Nous devons mettre à jour afin d’accéder aux nouveaux produits ! L’officiel Guide de mise à jour angulaire est toujours un bon point de départ. Mais la viande de la mise à jour est cette commande : ng update @angular/core@15 @angular/cli@15.

Maintenant, cette fille se heurte toujours à de nouveaux et passionnants problèmes de npm, donc je suis sûr que ce n’était qu’un coup de chance. Cela dit, si vous en rencontrez également pour vos applications angulaires, n’oubliez pas de supprimer votre node_modules dossier et votre package-lock.json et ré-exécution npm install après la mise à jour des dépendances peut vous sortir de nombreux pépins.

Pour cette dernière version, vous pouvez supprimer la ligne de votre tsconfig concernant enableIvy (puisque Ivy est la seule option de moteur de rendu pour la version 15 d’Angular).

Changements avec rupture

Ce changement de rupture particulier m’a attrapé: https://angular.io/guide/update-to-version-15#the-title-property-is-required-on-activatedroutesnapshot

Changer simplement « texte » en « titre » dans mes itinéraires a corrigé ceci :

src/app/app-routing.module.ts [old]

const routes: Routes = [
  { path: '', redirectTo: '/dashboard', pathMatch: 'full' },
  { path: 'detail/:id', component: HeroDetailComponent },
  { path: "dashboard", component: DashboardComponent, text: "Dashboard" },
  { path: "heroes", component: HeroesComponent, text: "Heroes" },
];

src/app/app-routing.module.ts

const routes: Routes = [
  { path: '', redirectTo: '/dashboard', pathMatch: 'full' },
  { path: 'detail/:id', component: HeroDetailComponent },
  { path: "dashboard", component: DashboardComponent, title: "Dashboard" },
  { path: "heroes", component: HeroesComponent, title: "Heroes" },
];

API autonomes

Comme évoqué ci-dessus, les API autonomes ne sont plus en aperçu pour les développeurs et sont prêtes pour une utilisation grand public avec la version 15 d’Angular. Pour commencer avec les composants autonomes, vous devriez consulter la vidéo de Jessica Janiuk ici dans la documentation : https://angular.io/guide/standalone-components#creating-standalone-components.

Il y a aussi quelques articles et dépôts que je recommande écrits par d’autres GDE :

Manfred Steyer [Articles]

Et l’article sur le composant Web concerne au moins indirectement les API autonomes :

Marko Stanimirovic [Article]
(Cet article est antérieur à la publication des API autonomes NgRx et Router.)

Dhananjay Kumar [Article]

Q Ray @ tipster22 [Repo]

Netanel Basal @NetanelBasal [Repo]

Lonli-Lokli @sirlonlilokli [Repo]

Suivez la récente chaîne Twitter de Mike Brocchi pour les dépôts émergents avec des API autonomes utilisées : https://twitter.com/Brocco/status/1593234105613058050

Donner un essai autonome

Tout ce battage médiatique autonome m’a eu démangeaison pour essayer cette fonctionnalité. Alors, j’ai sorti ma go-to-demo (Tour des poneys) et a décidé de l’essayer. Vous pouvez utiliser la CLI pour générer un composant autonome : ng -g component standalone-card --``standalone.

je veux remplacer mon hero-card composant avec ce composant autonome et voyez s’il y a une différence dans l’utilisation pratique. Jusqu’à présent, lors de la génération, la seule différence (à part le fait de ne pas être inclus dans un module) sont ces deux lignes dans le fichier TypeScript du composant :

Jessica le mentionne dans son tutorielmais le CommonModule importé ici est ce qui donne à notre composant autonome l’accès à des éléments tels que ngIf, ngFor et autres directives. Après avoir créé le composant autonome, nous devons toujours l’inclure dans notre module d’application afin que notre application le sache. Attention, ça va dans les importations, pas dans les déclarations.

Maintenant, j’ai remplacé la carte de héros par cette carte de composant autonome et j’ai même copié le balisage/la logique de notre carte de héros. Ces composants sont désormais identiques, sauf qu’un est sans module. Cependant, lorsque nous servons notre application, vous pouvez voir non seulement l’interface utilisateur mais aussi les erreurs de la console, notre composant autonome ne connaît pas les éléments de la bibliothèque de l’interface utilisateur de Kendo que nous utilisions dans hero-card.

Comme pour les modules de fonctionnalités, vous devez inclure vos dépendances dans le fichier TypeScript du composant, comme je l’ai fait ci-dessous pour le module Kendo UI Layout. (Il s’agit du package npm qui inclut les éléments souhaités kendo-card.)

Cependant, la carte de héros utilise également un tuyau personnalisé que j’ai créé et appelé ellipsis-pipe:

<p kendoCardSubtitle *ngIf="hero.residence" title="{{ hero.residence }}">{{ hero.alias }} from {{ hero.residence | ellipsis:25 }}</p>

Pour utiliser ce tube, nous devons l’exporter comme tel avec son propre module :

Ensuite, nous pouvons l’importer dans notre composant de carte autonome :

import { Component, Input } from '@angular/core';
import { CommonModule } from '@angular/common';
import { Hero } from '../hero';
import { LayoutModule } from '@progress/kendo-angular-layout';
import { AppRoutingModule } from '../app-routing.module';
import { PipesModule } from '../pipes/pipes.module';
import { EllipsisPipe } from '../pipes/ellipsis.pipe';
@Component({
  selector: 'standalone-card',
  standalone: true,
  imports: [CommonModule, LayoutModule, AppRoutingModule, PipesModule],
  templateUrl: './standalone-card.component.html',
  styleUrls: ['./standalone-card.component.css']
})
export class StandaloneCardComponent {
  @Input() hero: Hero;
}

CEPENDANT, l’API autonome vous permet non seulement de créer des composants sans modules, mais également des directives et des canaux. Il semble donc idiot de créer un composant de carte sans module, uniquement pour avoir besoin de créer un module pour notre tube personnalisé. Nous finirions par être neutres en termes de modules et nous essayons de réduire le nombre de modules dans notre application ! Rendons donc notre pipe autonome tout en l’exportant pour l’utiliser dans notre composant autonome.

Rendre notre tuyau angulaire autonome

C’était de loin la chose la plus simple que j’aie jamais faite dans Angular. 🔥 j’ai ajouté standalone: true à la déclaration de pipe, puis partout où j’importais le module pipes (app.module.ts et standalone-card.component.ts), j’ai plutôt simplement inclus le tuyau lui-même :

standalone-card.component.ts

import { Component, Input } from '@angular/core';
import { CommonModule } from '@angular/common';
import { Hero } from '../hero';
import { LayoutModule } from '@progress/kendo-angular-layout';
import { AppRoutingModule } from '../app-routing.module';
import { EllipsisPipe } from '../pipes/ellipsis.pipe';
@Component({
  selector: 'standalone-card',
  standalone: true,
  imports: [CommonModule, LayoutModule, AppRoutingModule, EllipsisPipe],
  templateUrl: './standalone-card.component.html',
  styleUrls: ['./standalone-card.component.css']
})
export class StandaloneCardComponent {
  @Input() hero: Hero;
}

Nous avons importé des choses comme commonModule, LayoutModule et AppRoutingModule parce que les composants autonomes gèrent leurs propres dépendances. Cela peut sembler être une étape supplémentaire, cependant, l’explicite en ligne est assez révélatrice de ce que vous utilisez réellement par composant. Je pense que c’est bien de l’avoir inclus ici, par rapport à un module d’application global ou même à un module de fonctionnalités. C’est plus verbeux au niveau des composants, mais moins d’étapes dans l’ensemble.

Et, aussi simple que cela, tous les endroits qui utilisaient autrefois mon composant de carte de héros utilisent maintenant ma carte autonome.

« Mais Alyssa », pourriez-vous vous dire, « à quoi ça servait tout ça ? Nous n’avons ajouté aucune nouvelle fonctionnalité. Et hélas, vous avez raison. Mais la porte que les choses sans module ouvrent est une porte passionnante et centrée sur les composants. Cela rend la face API de notre langage beaucoup plus simple et accessible aux débutants et beaucoup plus facile pour les mainteneurs. Personnellement, je suis ravi de le parcourir.

API de composition de directives

La prochaine étape de cette évolution sans module est la API de composition de directives, qui ouvre de nouvelles stratégies de réutilisation du code. Les directives de composition avec cette API ne fonctionnent qu’avec des directives autonomes (comme on pourrait l’imaginer) et étaient vraiment la pièce manquante dans ce puzzle sans module. 🧩

@Component({
  selector: 'navbar-anchor',
  template: 'navbar-anchor.html',
  hostDirectives: [AnchorFunc],
})
export class NavbarAnchor { }

Donc ici j’applique le AnchorFunc directive à l’élément hôte, NavbarAnchor. (Encore une fois, pour essayer certaines de ces choses, je recommande vivement les blogs de Manfred ci-dessus pour vous guider avec les documents officiels. Manfred est un enseignant 10/10.)

J’ai essayé de mettre notre pipe à l’intérieur de hostDirective, pour éviter de créer un module pour cela. Cependant, j’ai fini par planter l’ALS. Donc, je ne crois pas que les tuyaux soient pris en charge ici. Mais ça valait le coup d’essayer ! mdr

Donc, n’utilisez la fonctionnalité de composition de directives qu’avec des directives ET utilisez-les avec parcimonie.

Bien que l’API de composition de directives offre un outil puissant pour réutiliser les comportements courants, une utilisation excessive des directives hôtes peut avoir un impact sur l’utilisation de la mémoire de votre application. Si vous créez des composants ou des directives qui utilisent de nombreuses directives d’hôte, vous pouvez par inadvertance gonfler la mémoire utilisée par votre application. — Documents angulaires

Directive sur les images

La fonctionnalité de directive d’image est une autre fonctionnalité que je MORT D’ESSAYER. Alors essayons-le sur cette image arc-en-ciel dans l’en-tête !

Tout d’abord, nous devons inclure le module de la nouvelle directive image dans notre app.module.ts. Est-ce que je trouve ça bizarre qu’il ne soit pas autonome ? Oui, oui. Mais peut-être est-il trop tôt pour de telles choses ?

Maintenant, nous pouvons utiliser ngSrc à la place de src sur l’img arc-en-ciel. Cependant, cette directive d’image optimisée nécessite une largeur et une hauteur (ou fill mode) à rendre. Il existe des options dynamiques ainsi que des considérations pour différentes tailles d’écran en cours de route. J’ai été vraiment surpris de voir à quel point les docs se sentaient bien réfléchis à ce sujet –Vérifie-les!

<img src="https://www.telerik.com/blogs/assets/images/retro-mlp/my-littt-ponies-rainbow.png" alt="retro my little pony rainbow">
  <img ngSrc="https://www.telerik.com/blogs/assets/images/retro-mlp/my-littt-ponies-rainbow.png" width="670" height="200" alt="retro my little pony rainbow">

2022, c’est fini

Comme toujours, je suis super impressionné par cette dernière version d’Angular. J’adore ce framework et on m’a rappelé aujourd’hui que c’est plus que les fonctionnalités qui m’attirent. Cela a été et sera toujours le peuple.

j’organise une flux pour Enquête sur l’état du JS lors de sa sortie au début de l’année prochaine. J’ai toujours été une fille angulaire, donc mes relations de ce côté de JS sont naturellement plus fortes. Pour le stream de cette année, je voulais le mélanger et ajouter de nouveaux visages. La personne que j’avais en tête est un très gros poisson et un profil assez élevé, donc pas de DM ouverts pour eux. J’ai contacté le discord communautaire de leur framework pour tenter de contacter l’auteur. Bien sûr, je n’ai pas réussi à joindre cette personne. Pas une grosse affaire, je savais que c’était un long shot.

Cependant, ce à quoi je ne m’attendais pas, c’est le ridicule flagrant que j’ai eu pour avoir même osé parler dans cette discorde. On s’est même moqué de moi pour le peu que j’ai posté dans cette communauté. C’était un rappel brutal de la particularité de la communauté angulaire. Je sais que cette interaction n’était pas représentative de la communauté dans son ensemble ; cependant, je n’ai jamais ressenti cela en posant des questions stupides dans les canaux angulaires.

En fait, pour la démo ci-dessus, lorsque j’ai fait planter Angular Language Service, j’ai contacté l’équipe Angular à ce sujet. Non seulement ils m’ont dit que cela ne devrait pas arriver, mais l’a fait régler dans l’heure. Ils m’ont également informé, super gentiment, que les compositions directives n’étaient pas pour les tuyaux.

Je ne mentionne cela que parce que, alors que nous terminons cette année et que nous regardons en arrière, nous pourrions peut-être aussi regarder vers l’avenir. En fin de compte, nous sommes tous des développeurs Web qui ne faisons que vivre sur le dos de JavaScript. Nous devrions être plus gentils les uns envers les autres, peu importe nos origines. La façon dont vous répondez à quelqu’un compte, parfois beaucoup. Apportons de la gentillesse dans nos communautés cette année prochaine et rendons-la plus inclusive pour tous. Joyeuses fêtes à tous et bonne Angular v15 !