Search for a command to run...
Très intéressant cet article, j'apprends énormément à travers vos articles. Vivement que ça continue 🙏🏽😊
Intéressant comme article. Perso, je ne connaissais pas cette directive, mais ça me sera utile.
Depuis l'arrivée des Signals dans Angular, une question revient sans cesse dans les équipes : comment continuer à profiter de la puissance de RxJS, de ses opérateurs, de sa gestion fine des flux async
Si vous suivez l'actualité d'Angular avec la sortie de la version 20 du framework, vous avez probablement entendu de plus en plus ce terme. Mais au-delà du jargon, qu'est-ce que le Zoneless concrètement pour vos applications Angular ? Pourquoi est-il...
Si vous avez l’habitude de manipuler des formulaires réactifs (Reactive Forms) dans un projet Angular, vous connaissez certainement la méthode patchValue(…). Cette méthode, permet de mettre à jour les valeurs de votre formulaire. Cependant, son utili...
Depuis la sortie de la version 17 du framework Angular, on parle de la renaissance de Angular. Il y a eu beaucoup de changements majeurs depuis la version 16 du framework pour préparer le terrain à cette renaissance. Ces changements majeurs ont rendu...
Dans notre précédent article, nous avons vu ensemble ce qu'est un Signal Input et comment l'utiliser. Nous avons particulièrement remarqué sa similarité avec le décorateur @Input(). Dans ce nouvel article, nous verrons ensemble un nouveau type de inp...
Dans vos applications Angular, vous avez certainement l'habitude d'utiliser le pipe async pour souscrire à un Observable afin de récupérer les données émises. Ce pipe, dans sa particularité permet aussi de détruire cet Observable de façon implicite dès que la souscription est complète.
Prenons cet exemple de code :
<ul>
<li *ngFor="let number of numbers$ | async">
{{ number }}
</li>
</ul>
Que se passera t-il, lorsque la souscription à l'
Observableretournera une erreur ? Rien ! On ne peut pas signaler à l'utilisateur qu'il y a un problème par exemple 😱
On fait face à un souci d'expérience utilisateur😫
Lorsque l'Observable retourne une erreur, rien ne se passe du côté du pipe async. Il n'y a pas un moyen de traiter l'erreur. C'est dérangeant car l'on aimerait quand même afficher un message d'erreur au niveau de notre template afin d'avoir une bonne expérience utilisateur.
Pas de panique ! Une solution existe 😁
Levons nos verres 🥂 à la directive*ngrxLetde la bibliothèque@ngrx/component.
En effet, la directive *ngrxLet, en plus de ce que le pipe async permet de faire déjà, récupère les trois (03) évènements liés à la souscription d'un Observable à savoir :
next
error
complete
Examinons ce code :
<ng-container *ngrxLet="number$ as n; error as e; complete as c">
<app-number [number]="n" *ngIf="!e && !c">
</app-number>
<p *ngIf="e">There is an error: {{ e }}</p>
<p *ngIf="c">Observable is completed.</p>
</ng-container>
numbers$ est un Observable. Lorsqu'on souscrit à ce dernier au niveau de la classe TS, voici ce à quoi on devrait s'attendre :number$.subscribe({
next: x => console.log(x),
error: err => console.error(err),
complete: () => console.log('Observer got a complete notification')
});
En comparaison avec le code HTML précédent, on a :
number$ as n => next
error as e => error
complete as c => complete
Pour rajouter cette directive à votre projet, voici comment procéder :
Installer le package @ngrx/component :
ng add @ngrx/component@latest
Ajouter le module LetModule dans le module de votre composant :
import { LetModule } from '@ngrx/component';
imports: [
// ... other imports
LetModule,
],
En somme, pour améliorer l'expérience utilisateur de vos applications tout en écrivant moins de code au niveau de votre classe TS, vous savez quoi faire à présent !
Pour plus d'informations 👉 NgRx - Let Directive