Gestion des abonnements dans les composants Angular sans se répéter

Bonjour, aujourd’hui nous allons parler d’Angular, plus précisément de la gestion des abonnements dans les composants sans répéter la même logique de démontage dans chaque composant.

Nous avons deux manières courantes de gérer les abonnements RxJS (Reactive extensions for JavaScript) dans les composantsAngular pour éviter les fuites de mémoire : la méthode de l’abonnement et celle de destruction des sujets (désabonnement).

Destruction des sujets (désabonnement) :

Pour ce faire, il faut initialiser la propriété supplémentaire et ajouter une logique de démontage à la méthode ngOnDestroy, ce qui est un grand inconvénient. Afin de palier à cet inconvénient, il existe un meilleur moyen de gérer les abonnements dans les composants Angular.

D’abord, nous pouvons mettre la logique de démontage à un seul endroit en créant une classe Destroy qui va étendre la classe Observable et implémenter l’interface OnDestroy.

Ensuite, nous pouvons fournir la classe Destroy au niveau du composant et l’injecter via le constructeur. De ce fait, lorsqu’un fournisseur sera fourni au niveau du composant, il sera lié au cycle de vie du composant, ce qui nous permettra d’utiliser la méthode de cycle de vie ngOnDestroy en son sein. Par conséquent, la méthode ngOndestroy du fournisseur Destroy sera appelée lorsque IntervalComponent est détruite. Généralement, les désabonnements/abonnements manuels dans les composants Angular doivent être évités, Si vous devez effectuer un effet secondaire au niveau du composant, vous pouvez le faire en utilisant @ngrx/component-store et laisser ComponentStore prendre soin d’éviter les fuites de mémoire. Cependant, si vous préférez gérer les effets secondaires dans les composants, pensez à utiliser le fournisseur Destroy pour éviter de répéter la même logique de démontage dans chaque composant.