Le Guide Angular | Marmicode
  • Le Guide Angular par Marmicode
  • Pourquoi Angular ?
  • ECMAScript 6+
    • Un Peu d'Histoire
    • Propriétés du Langage
    • "Single-Threaded" donc Asynchrone
    • Event Loop
    • Classes
    • Hoisting is Dead: var vs. let vs. const
    • this & "binding"
    • Arrow Functions
    • Template Strings
    • Syntactic Sugar
      • Spread
      • Destructuring
      • Rest
      • Object Literal Property Value Shorthand
    • Named Parameters
    • Compatibilité
  • TypeScript
    • Pourquoi TypeScript ?
    • De l'ECMAScript au TypeScript
    • Visibilité des Propriétés
    • Typing des Propriétés
    • Types
    • Interfaces
    • Inference
    • Duck Typing
    • Duck Typing Patterns
      • Compatibilité de Librairies
      • Entity Constructor
    • Décorateurs
      • Décorateurs de Propriété
      • Décorateurs de Classe
      • Décorateurs de Méthode & Paramètres
    • Quelques Liens
  • Tools
    • Clavier mécanique
    • Git
    • Command Line
    • NodeJS
    • NPM
    • Yarn
      • Pourquoi Yarn ?
      • Définition et Installation des Dépendances
      • Scripts
      • Mise à Jour et Automatisation
    • Chrome
    • IntelliJ / WebStorm / VSCode
      • Raccourcis clavier IntelliJ / WebStorm
    • Floobits
    • Angular CLI
    • StackBlitz
    • Compodoc
  • Angular
    • Bootstrap
    • Composants
      • Root Component
      • Template Interpolation
      • Property Binding
      • Class & Style Binding
      • Event Binding
      • *ngIf
      • *ngFor
      • L'approche MVC
      • Création de Composants
      • Exemple
    • Container vs. Presentational Components
    • Interaction entre Composants
      • Input
      • Output
      • Exemple
    • Change Detection
      • Les Approches Possibles
      • Fonctionnement de la Change Detection
      • Optimisation de la Change Detection
      • Immutabilité
      • Quelques Liens
    • Project Structure & Modules
      • Entry Point
      • Définition d'un Module
      • Root Module
      • Feature Module
      • Shared Module
      • Exemple
    • Dependency Injection
      • Qu'est-ce que la "Dependency Injection" ?
      • Injection d'un Service Angular
      • Services & Providers
      • Portée des Services
      • Tree-Shakable Services
      • Class vs Injection Token
      • Exemple
    • Callback Hell vs. Promise vs. Async / Await
      • Callback Hell
      • Promise
      • Async / Await
    • Observables
      • Reactive Programming
      • Promise vs Observable
      • Subscribe
      • Unsubscribe ⚠️
      • Création d'un Observable
      • Opérateurs
        • Définition d'un Opérateur
        • Lettable Operators vs Legacy Methods
        • map
        • filter
        • mergeMap & switchMap
        • shareReplay
        • buffer
        • debounceTime
        • distinctUntilChanged
        • retry
      • Quelques Liens
      • Talks
    • Http
      • Pourquoi HttpClient ?
      • Utilisation de HttpClient
      • Utilisation dans un Service
      • Gestion de la Subscription ⚠️
    • State Management
      • Quelques Liens
      • Talks
    • GraphQL
    • Formulaires
      • Template-driven Forms 🤢
      • Reactive Forms 👍
        • Avantages des "Reactive Forms"
        • La boite à outils des "Reactive Forms"
        • Validation
        • Observation des Changements
    • Directives
      • Attribute Directive
      • Structural Directive
    • Pipes
    • Routing
      • Mise en Place du Routing
      • Lazy Loading
      • Project Structure
      • Route Guards
    • Testing
      • Unit-Testing
        • 📺Introduction au Test-Driven Development
        • Jasmine
        • Unit-Test Synchrone
        • Test-Driven Development
        • Unit-Test Asynchrone
        • TestBed
        • Unit-Test d'un Service
        • Unit-Test d'un Composant
        • Unit-Test et Spies
        • Unit-Test et HttpClient
      • End-to-End
      • Talks
    • Sécurité
      • Quelques Liens
    • Animation
    • Internationalisation
    • Quelques Liens
  • Cookbook
    • Authentification et Autorisation
    • Remplacement Dynamique de Composants
    • Lazy Loading without Router
    • Project Structure
    • SCAM Modules
    • Setup a Mock ReSTful API
  • Autres Ressources
  • Stay Tuned
    • 🎁-20% sur nos workshops avec le code GUIDEANGULAR
    • 🐦Suivez-moi !
    • 📺Cours Vidéo
    • 📬Newsletter
    • 📝Blog
  • Nos Services
    • Formation Angular
    • Atelier Unit-Testing Angular
    • Atelier Architecture Angular
    • Consultation à Distance & Code Review
  • Nos Guides
    • Guide Agile
    • Guide API ReST
    • Guide NodeJS
Propulsé par GitBook
Sur cette page
  • Unsubscribe dans ngOnDestroy
  • Unsubscribe avec l'opérateur takeUntil
  • Exemple
  • Unsubscribe avec le Pipe async
  • A éviter
  • Fonctionnement du "pipe" async
  • Gotcha
  • shareReplay
  • Gestion d'erreurs
  • Exemple
  • RxScavenger
  1. Angular
  2. Http

Gestion de la Subscription ⚠️

PrécédentUtilisation dans un ServiceSuivantState Management

Dernière mise à jour il y a 5 ans

Dans les exemples ci-dessus, l'objet Subscription retourné par la méthode subscribe est simplement ignoré.

Il faut s'assurer que le composant unsubscribe de l'Observable avant sa destruction (et également si une nouvelle requête est déclenchée par exemple en cas de "refresh").

Dans le cas d'Observables infinis cela évite des fuites mémoire et surconsommation CPU.

Dans notre cas, cela évite la congestion des requêtes HTTP (dans le cas où le composant est détruit et reconstruit plusieurs fois rapidement par exemple ou encore lors de la navigation sur l'application via le ).

Unsubscribe dans ngOnDestroy

On profite généralement du "Lifecycle Hook" ngOnDestroy pour déclencher l'unsubscribe.

private _bookListSubscription: Subscription;

constructor(private _bookRepository: BookRepository) {
}

ngOnInit() {
    this._bookListSubscription = this._bookRepository.getBookList()
        .subscribe(bookList => this.bookList = bookList);
}

ngOnDestroy() {
    this._bookListSubscription.unsubscribe();
}

Et par précaution dans le cas où la subscription est créé plus tard.

ngOnDestroy() {
    if (this._bookListSubscription != null) {
        this._bookListSubscription.unsubscribe();
    }
}

L'inconvénient de cette approche est sa verbosité. Elle en devient "error-prone".

Unsubscribe avec l'opérateur takeUntil

export class BookSearchComponent implements OnDestroy, OnInit {

    bookList: Book[];

    private _isDead$ = new Subject();

    constructor(private _bookRepository: BookRepository) {
    }

    ngOnInit() {
        this._bookRepository.getBookList()
            .pipe(takeUntil(this._isDead$))
            .subscribe(bookList => this.bookList = bookList);
    }

    ngOnDestroy() {
        this._isDead$.next();
    }

}

Il existe une approche similaire avec l'opérateur takeWhile qui se base sur un valeur "boolean" plutôt qu'un Observable mais il est préférable de l'éviter.

Contrairement à l'approche takeUntil, takeWhile ne peut pas détecter en temps réel le changement de la variable "boolean" et la requête HTTP ne sera donc pas interrompue.

Exemple

Dans les cas les plus simples, cette approche est la plus adaptée car c'est la moins verbeuse est la plus réactive.

Le "pipe" async permet de préparer l'Observable dans le composant et laisser la vue subscribe quand elle en a besoin et si elle en a besoin.

export class BookSearchComponent {

    bookList$: Observable<Book[]>;

    constructor(private _bookRepository: BookRepository) {
        this.bookList$ = this._bookRepository.getBookList();
    }

}

Remarquez que l'on se permet de créer l'Observable directement dans le constructeur. En effet, tant que l'on ne subscribe pas, aucun traitement n'est déclenché.

A éviter

Il est possible d'utiliser la syntaxe perturbante ci-dessous mais il est préférable de l'éviter.

export class BookSearchComponent {

    bookList$ = this._bookRepository.getBookList();

    constructor(private _bookRepository: BookRepository) {
    }

}

Fonctionnement du "pipe" async

<wt-book-preview
        *ngFor="let book of bookList$ | async"
        [book]="book"></wt-book-preview>

Le "pipe" async subscribe à l'Observable bookList$ et permet de mettre à jour la vue en conséquence.

A la destruction de l'élément (e.g. : "toggle" de la liste via *ngIf), le "pipe" async unsubscribe automagiquement.

Gotcha

En essayant d'afficher le nombre de "book" en créant un autre Observable :

export class BookSearchComponent {

    bookCount$: Observable<number>;
    bookList$: Observable<Book[]>;

    constructor(private _bookRepository: BookRepository) {
        this.bookList$ = this._bookRepository.getBookList();
        this.bookCount$ = this.bookList$.pipe(map(bookList => bookList.length));
    }

}
<div>{{ bookCount$ | async }}</div>

<wt-book-preview
        *ngFor="let book of bookList$ | async"
        [book]="book"></wt-book-preview>

Cela "fonctionne" mais on peut remarquer que la requête HTTP a été exécutée deux fois.

L'Observable créé par le service HttpClient est de type "Cold" (c'est à dire Lazy). Chaque "pipe" async appelle la méthode subscribe et déclenche donc la requête HTTP puis les traitements appliqués par les opérateurs (l'opérateur map dans notre cas).

shareReplay

Le comportement souhaité est le suivant :

  • Tant qu'il n'y a aucun appel à subscribe (explicite ou implicite via async), le traitement ne doit pas s'exécuter.

  • Au premier subscribe, le traitement doit être déclenché.

  • Les subscribes supplémentaires ne doivent pas redéclencher le traitement mais simplement attendre le résultat.

  • Les souscripteurs qui arrivent après la récupération du résultat doivent récupérer la dernière valeur obtenue.

L'intégralité de se traitement se fait simplement avec l'opérateur shareReplay en lui indiquant en paramètre la taille du buffer de mémorisation. Un buffer de taille 1 va mémoriser la dernière valeur.

Le problème décrit au paragraphe précédent est alors résolu ainsi :

export class BookSearchComponent {

    bookCount$: Observable<number>;
    bookList$: Observable<Book[]>;

    constructor(private _bookRepository: BookRepository) {
        this.bookList$ = this._bookRepository.getBookList()
            .pipe(shareReplay(1));
        this.bookCount$ = this.bookList$.pipe(map(bookList => bookList.length));
    }

}

Gestion d'erreurs

Pour capturer les erreurs et détecter la fin du traitement (i.e. try / catch / finally), il suffit d'utiliser les opérateurs catchError et finalize.

EMPTY est une constante contenant un Observable vide. Vous êtes libres de retourner un Observable contenant des données (de secours) provenant d'une autre source (cache etc...).

import { EMPTY, Observable } from 'rxjs';
import { catchError, finalize, map, shareReplay } from 'rxjs/operators';

this.bookList$ = this._bookRepository.getBookList()
    .pipe(
        catchError(error => {
            console.error(error);
            return EMPTY;
        }),
        finalize(() => {
            console.log('Done!');
        }),
        shareReplay(1)
    );

Exemple

Pour reproduire l'erreur ci-dessus, vous pouvez bloquer le domaine de l'API sur Chrome via le menu décrit ci-dessous.

RxScavenger

Unsubscribe avec le async

Routing
https://github.com/wishtack/wishtack-book-shop/tree/7-unsubscribe-using-take-until
Pipe
https://github.com/wishtack/wishtack-book-shop/tree/8-unsubscribe-using-async-pipe
https://blog.wishtack.com/2018/05/30/handle-rxjs-subscriptions-properly-using-rx-scavenger/
LogoWishtack - Wishtack Book Shop - StackBlitzStackBlitz
LogoWishtack - Wishtack Book Shop - StackBlitzStackBlitz
LogoHandle RxJS Subscriptions Properly Using Rx-ScavengerWishtack
Observables ❤️async pipe ❤️retry
Chrome Block request