Angulaire/RxJs Quand dois-je me désinscrire "Abonnement"

--- Edition 4 - Des Ressources Supplémentaires (2018/09/01)

Dans un récent épisode de Aventures dans Angulaire Ben Lesh et de la Paroisse de Bell examiner les questions autour de comment/quand vous désabonner en un composant. La discussion commence à 1:05:30.

Paroisse mentionne right now there's an awful takeUntil dance that takes a lot of machinery et Shai Reznik mentionne Angular handles some of the subscriptions like http and routing.

En réponse Ben mentionne qu'il y a des discussions en ce moment pour permettre à des Observables pour accrocher dans l'angle de la composante du cycle de vie des événements et de la Paroisse suggère une Observable des événements du cycle de vie d'un composant peut s'abonner à un moyen de savoir quand terminer Observables maintenu en tant que composante interne de l'état.

Cela dit, nous avons surtout besoin de solutions maintenant donc, voici quelques autres ressources.

1. Une recommandation pour la takeUntil() modèle de RxJs membre de l'équipe noyau Nicolas Jamieson et un tslint règle pour l'aider à la faire respecter. https://blog.angularindepth.com/rxjs-avoiding-takeuntil-leaks-fb5182d047ef

2. Léger mnp package qui expose une Observable de l'opérateur qui prend une instance de composant (this) en tant que paramètre et se désinscrit automatiquement lors de ngOnDestroy.
   https://github.com/NetanelBasal/ngx-take-until-destroy

3. Une autre variation de la ci-dessus avec un peu meilleure ergonomie, si vous ne faites AOT versions (mais nous devrions tous faire de AOT maintenant).
   https://github.com/smnbbrv/ngx-rx-collector

4. Personnalisé directive *ngSubscribe qui fonctionne comme async pipe, mais crée une vue intégrée dans votre modèle de sorte que vous pouvez vous référer à la "déballé" valeur tout au long de votre modèle.
   https://netbasal.com/diy-subscription-handling-directive-in-angular-c8f6e762697f

Je le mentionne dans un commentaire à Nicolas blog que la sur-utilisation de takeUntil() pourrait être un signe que votre composant est d'essayer d'en faire trop et que la séparation de vos composants existants dans Fonction et de Présentation composants doivent être considérés. Vous pouvez ensuite | async Observables à partir de la Fonctionnalité du composant dans un Input de la Présentation du composant, ce qui signifie aucun abonnement n'est nécessaire, n'importe où. Lire plus sur cette approche ici

--- Edition 3 - Le "Officielle" De La Solution (2017/04/09)

J'ai parlé avec de la Paroisse de Bell à propos de cette question à NGConf (j'ai même lui a montré cette réponse qu'il a dit est correct) mais il m'a dit à l'équipe docs Angulaire a une solution à cette question qui est inédit (bien qu'ils travaillent sur l'obtenir approuvé). Il m'a aussi dit que je pouvais mettre à jour mon DONC réponse à la recommandation officielle.

La solution que nous devrions tous utiliser à l'avenir est d'ajouter un private ngUnsubscribe = new Subject(); champ à tous les composants qui ont .subscribe() appels à Observables au sein de leur classe code.

Nous appelons alors this.ngUnsubscribe.next(); this.ngUnsubscribe.complete(); dans notre ngOnDestroy() méthodes.

Le secret de la sauce (comme cela a déjà été noté par @metamaker) est d'appeler takeUntil(this.ngUnsubscribe) avant chacune de nos .subscribe() appels, qui permettra de garantir à tous les abonnements seront nettoyés, lorsque le composant est détruit.

Exemple:

import { Component, OnDestroy, OnInit } from '@angular/core';
//RxJs 6.x+ import paths
import { filter, startWith, takeUntil } from 'rxjs/operators';
import { Subject } from 'rxjs';
import { BookService } from '../books.service';

@Component({
    selector: 'app-books',
    templateUrl: './books.component.html'
})
export class BooksComponent implements OnDestroy, OnInit {
    private ngUnsubscribe = new Subject();

    constructor(private booksService: BookService) { }

    ngOnInit() {
        this.booksService.getBooks()
            .pipe(
               startWith([]),
               filter(books => books.length > 0),
               takeUntil(this.ngUnsubscribe)
            )
            .subscribe(books => console.log(books));

        this.booksService.getArchivedBooks()
            .pipe(takeUntil(this.ngUnsubscribe))
            .subscribe(archivedBooks => console.log(archivedBooks));
    }

    ngOnDestroy() {
        this.ngUnsubscribe.next();
        this.ngUnsubscribe.complete();
    }
}

Remarque: Il est important d'ajouter le takeUntil opérateur en dernier pour éviter les fuites avec des intermédiaires observables dans l'opérateur de la chaîne.

--- Edit 2 (2016/12/28)

Source 5

L'angle de tutoriel, le chapitre Routage indique désormais le suivant: "Le Routeur gère les observables et localise les abonnements. Les abonnements sont nettoyés lorsque le composant est détruit, la protection contre les fuites de mémoire, de sorte que nous n'avons pas besoin de vous désinscrire de la route des paramètres Observables." - Marque Rajcok

Voici un discussion sur le Github de questions pour l'angle d'docs concernant Routeur Observables où Paroisse Bell mentionne que des éclaircissements pour tout ceci est dans les travaux.

--- Edit 1

Source 4

Dans ce vidéo de NgEurope Rob Wormald également dit que vous n'avez pas besoin de vous désinscrire de Routeur Observables. Il mentionne aussi la http service et ActivatedRoute.params dans ce la vidéo à partir de novembre 2016.

--- Réponse Originale À Cette Question

TLDR:

Pour cette question, il y a (2) types de Observables - finis valeur et infini valeur.

http Observables produire finis (1) les valeurs et quelque chose comme un DOM event listener Observables produire infini valeurs.

Si vous avez manuellement appel subscribe (n'utilisant pas async pipe), puis unsubscribe de infini Observables.

Ne vous inquiétez pas à propos de finis ceux, RxJs de prendre soin d'eux.

Source 1

J'ai dégotté une réponse de Rob Wormald Angulaire du Gitter ici.

Il déclare (j'ai réorganisé pour la clarté et l'emphase est mienne)

si son une seule valeur de la séquence (comme une requête http)
le nettoyage manuel est inutile (en supposant que vous vous inscrivez dans le contrôleur manuellement)

je devrais dire "si c'est un séquence complète" (dont l'unique valeur de séquences, une la http, ne font qu'un)

si son d'une séquence infinie, vous devez vous désabonner qui async pipe fait pour vous

Aussi qu'il mentionne dans ce vidéo youtube sur des Observables qui they clean up after themselves... dans le contexte d'Observables qui complete (comme des Promesses, toujours parfaits parce qu'ils sont toujours la production de valeur 1 et se terminant - nous n'avons jamais inquiet au sujet de vous désabonner de Promesses pour s'assurer qu'ils nettoyer xhr des écouteurs d'événement, non?).

Source 2

Également dans le Rangle guide Angulaire 2 il lit

Dans la plupart des cas nous n'aurons pas besoin d'appeler explicitement la méthode de désabonnement a moins de vouloir annuler tôt ou notre Observable a une durée de vie plus longue de notre abonnement. Le comportement par défaut de l'Observable opérateurs est de disposer de l'abonnement dès que .complet() ou .erreur() les messages sont publiés. Gardez à l'esprit que RxJS a été conçu pour être utilisé dans un "fire and forget" de la mode la plupart du temps.

Lorsque le membre de phrase our Observable has a longer lifespan than our subscription appliquer?

Elle s'applique lorsqu'un abonnement est créé à l'intérieur d'un composant qui est détruit avant (ou pas long avant) le Observable complète.

J'ai lu ce sens que si nous sommes abonnés à un http demande ou à une observable qui émet des 10 valeurs et notre composant est détruit avant que http demande les rendements ou les 10 valeurs ont été émises, nous sommes toujours ok!

Lors de la demande de retour ou de la 10e valeur est enfin émis le Observable sera terminé et que toutes les ressources seront nettoyés.

Source 3

Si l'on regarde cet exemple de la même Rangle guide, nous pouvons voir que la Subscription à route.params nécessite une unsubscribe() parce que nous ne savons pas quand ces params va cesser de les changer (par émission de nouvelles valeurs).

Le composant pourrait être détruit par de naviguer à l'extérieur, auquel cas le paramètre de route sera probablement encore être en train de changer (ils pourraient techniquement le modifier jusqu'à ce que l'application se termine) et les ressources allouées à la souscription serait encore alloués car il n'a pas été un completion.

La classe d'Abonnement a une caractéristique intéressante:

Représente un revenu de ressources, telles que l'exécution d'un fait Observable. Un Abonnement a une méthode importante, de désabonnement, qui ne prend aucun argument et simplement dispose de la ressource détenue par l'abonnement.

En outre, les abonnements peuvent être regroupés par le biais de la méthode add (), qui va attacher un enfant de Souscription à l'Abonnement en cours. Lorsqu'un Abonnement est précisé, à tous ses enfants (et de ses petits-enfants) va être désabonné ainsi.

Vous pouvez créer une Souscription global de l'objet, qui regroupe tous vos abonnements.
Vous faites cela en créant un vide d'Abonnement et de ajoutant des abonnements à l'aide de son add() méthode. Lorsque votre composant est détruit, il vous suffit de vous désabonner de la souscription total.

@Component({ ... })
export class SmartComponent implements OnInit, OnDestroy {
  private subscriptions = new Subscription();

  constructor(private heroService: HeroService) {
  }

  ngOnInit() {
    this.subscriptions.add(this.heroService.getHeroes().subscribe(heroes => this.heroes = heroes));
    this.subscriptions.add(/* another subscription */);
    this.subscriptions.add(/* and another subscription */);
    this.subscriptions.add(/* and so on */);
  }

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

Il dépend. Si en appelant someObservable.subscribe(), vous commencez à la tenue de certaines ressources qui doivent être manuellement libérée lorsque le cycle de vie du composant est terminée, alors vous devriez appeler theSubscription.unsubscribe() pour empêcher la fuite de mémoire.

Nous allons regarder de plus près à votre exemples:

getHero() retourne le résultat de http.get(). Si vous regardez dans l'angle de 2 le code source, http.get() crée deux écouteurs d'événement:

_xhr.addEventListener('load', onLoad);
_xhr.addEventListener('error', onError);

et en appelant unsubscribe(), vous pouvez annuler la demande ainsi que les auditeurs:

_xhr.removeEventListener('load', onLoad);
_xhr.removeEventListener('error', onError);
_xhr.abort();

Noter que _xhr de la plate-forme, mais je pense qu'il est sûr de supposer que c'est un XMLHttpRequest() dans votre cas.

Normalement, c'est assez de preuves pour justifier un manuel unsubscribe() appel. Mais selon ce WHATWG spec, le XMLHttpRequest() est soumise à la collecte des déchets une fois qu'il est "fait", même si il y a des écouteurs d'événement attaché à elle. Donc je suppose que c'est pourquoi angulaire 2 guide officiel qui omet unsubscribe() et vous permet de GC nettoyer les auditeurs.

Comme pour votre deuxième exemple, il dépend de la mise en œuvre de params. À compter d'aujourd'hui, l'angle de guide officiel n'affiche plus de se désabonner de params. J'ai regardé dans src encore et a constaté que params est un juste un BehaviorSubject. Depuis aucun cas, les auditeurs ou des minuteries ont été utilisés, et pas de variables globales ont été créé, il devrait être sûr d'omettre unsubscribe().

La ligne de fond à votre question qui est toujours d'appel unsubscribe() une protection contre la fuite de mémoire, sauf si vous êtes certain que l'exécution de l'observable n'est pas de créer des variables globales, ajouter des écouteurs d'événement, régler les minuteries, ou faire autre chose qui entraîne des fuites de mémoire.

En cas de doute, regardez dans la mise en œuvre de cette observable. Si l'observable a écrit nettoyer une partie de la logique dans ses unsubscribe(), qui est généralement de la fonction qui est renvoyé par le constructeur, alors vous avez une bonne raison de réfléchir sérieusement à l'appel de unsubscribe().

Basée sur : À l'aide de l'héritage de Classe à crochet Angulaire 2 composante du cycle de vie

Une autre approche générique:

JS:

export abstract class UnsubscribeOnDestroy implements OnDestroy {
  protected d$: Subject<any>;

  constructor() {
    this.d$ = new Subject<void>();

    const f = this.ngOnDestroy;
    this.ngOnDestroy = () => {
      f();
      this.d$.next();
      this.d$.complete();
    };
  }

  public ngOnDestroy() {
    //no-op
  }

}

Et d'utilisation :

JS:

@Component({
    selector: 'my-comp',
    template: ``
})
export class RsvpFormSaveComponent extends UnsubscribeOnDestroy implements OnInit {

    constructor() {
        super();
    }

    ngOnInit(): void {
      Observable.of('bla')
      .takeUntil(this.d$)
      .subscribe(val => console.log(val));
    }
}

Officielle de l'Édition #3 réponse (et variations) fonctionne bien, mais la chose qui me surprend est la "boue" de la logique d'entreprise autour de l'observable abonnement.

Voici une autre approche à l'aide de papiers d'emballage.

Warining: code expérimental

Fichier subscribeAndGuard.ts est utilisé pour créer un nouveau Observable extension pour envelopper .subscribe() et à l'intérieur de retour à la ligne ngOnDestroy().

L'utilisation est la même que .subscribe(), sauf pour un supplément de premier paramètre le référencement du composant.

import { Observable } from 'rxjs/Observable';
import { Subscription } from 'rxjs/Subscription';

const subscribeAndGuard = function(component, fnData, fnError = null, fnComplete = null) {

  //Define the subscription
  const sub: Subscription = this.subscribe(fnData, fnError, fnComplete);

  //Wrap component's onDestroy
  if (!component.ngOnDestroy) {
    throw new Error('To use subscribeAndGuard, the component must implement ngOnDestroy');
  }
  const saved_OnDestroy = component.ngOnDestroy;
  component.ngOnDestroy = () => {
    console.log('subscribeAndGuard.onDestroy');
    sub.unsubscribe();
    //Note: need to put original back in place
    //otherwise 'this' is undefined in component.ngOnDestroy
    component.ngOnDestroy = saved_OnDestroy;
    component.ngOnDestroy();

  };

  return sub;
};

//Create an Observable extension
Observable.prototype.subscribeAndGuard = subscribeAndGuard;

//Ref: https://www.typescriptlang.org/docs/handbook/declaration-merging.html
declare module 'rxjs/Observable' {
  interface Observable<T> {
    subscribeAndGuard: typeof subscribeAndGuard;
  }
}

Ici est un composant avec deux abonnements, l'un avec l'enveloppe et l'autre sans. Le seul inconvénient est qu'il doit mettre en œuvre OnDestroy (avec vide de corps, si vous le désirez), sinon Angulaire ne sais pas à appeler le enveloppés version.

import { Component, OnInit, OnDestroy } from '@angular/core';
import { Observable } from 'rxjs/Observable';
import 'rxjs/Rx';
import './subscribeAndGuard';

@Component({
  selector: 'app-subscribing',
  template: '<h3>Subscribing component is active</h3>',
})
export class SubscribingComponent implements OnInit, OnDestroy {

  ngOnInit() {

    //This subscription will be terminated after onDestroy
    Observable.interval(1000)
      .subscribeAndGuard(this,
        (data) => { console.log('Guarded:', data); },
        (error) => { },
        (/*completed*/) => { }
      );

    //This subscription will continue after onDestroy
    Observable.interval(1000)
      .subscribe(
        (data) => { console.log('Unguarded:', data); },
        (error) => { },
        (/*completed*/) => { }
      );
  }

  ngOnDestroy() {
    console.log('SubscribingComponent.OnDestroy');
  }
}

Une démo plunker est ici

Une note supplémentaire:
Re Edit 3 - Le "Officielle" de la Solution, cela peut être simplifiée par l'utilisation de takeWhile() au lieu de takeUntil() avant d'abonnements, et un simple booléen plutôt qu'un autre Observable dans ngOnDestroy.

@Component({...})
export class SubscribingComponent implements OnInit, OnDestroy {

  iAmAlive = true;
  ngOnInit() {

    Observable.interval(1000)
      .takeWhile(() => { return this.iAmAlive; })
      .subscribe((data) => { console.log(data); });
  }

  ngOnDestroy() {
    this.iAmAlive = false;
  }
}

J'ai essayé seangwright la solution de (Edition 3)

Qui ne fonctionne pas pour les Observables qui a créé par minuterie ou un intervalle.

Cependant, j'ai eu de travail en utilisant une autre approche:

import { Component, OnDestroy, OnInit } from '@angular/core';
import 'rxjs/add/operator/takeUntil';
import { Subject } from 'rxjs/Subject';
import { Subscription } from 'rxjs/Subscription';
import 'rxjs/Rx';

import { MyThingService } from '../my-thing.service';

@Component({
   selector: 'my-thing',
   templateUrl: './my-thing.component.html'
})
export class MyThingComponent implements OnDestroy, OnInit {
   private subscriptions: Array<Subscription> = [];

  constructor(
     private myThingService: MyThingService,
   ) { }

  ngOnInit() {
    const newSubs = this.myThingService.getThings()
        .subscribe(things => console.log(things));
    this.subscriptions.push(newSubs);
  }

  ngOnDestroy() {
    for (const subs of this.subscriptions) {
      subs.unsubscribe();
   }
 }
}

Vous avez généralement besoin de se désabonner quand les composants sont détruits, mais Angulaire va gérer de plus en plus que nous allons, par exemple dans la nouvelle version mineure de Angular4, ils ont cette section pour le routage de désabonnement:

Avez-vous besoin pour vous désabonner?

Comme décrit dans la
ActivatedRoute: le one-stop-shop pour les informations sur l'itinéraire de la section de la
Routage & Navigation de page, le Routeur gère les observables c'
fournit et localise les abonnements. Les abonnements sont
nettoyé lorsque le composant est détruit, la protection contre la mémoire
les fuites, de sorte que vous n'avez pas besoin de vous désinscrire de la route paramMap
Observables.

L'exemple ci-dessous est un bon exemple de Angulaire de la création d'un composant et de le détruire après, regardez comment les composant implémente OnDestroy, si vous avez besoin d'onInit, vous pouvez également l'implémente dans votre composant, comme le met en œuvre OnInit, OnDestroy

import { Component, Input, OnDestroy } from '@angular/core';  
import { MissionService } from './mission.service';
import { Subscription }   from 'rxjs/Subscription';

@Component({
  selector: 'my-astronaut',
  template: `
    <p>
      {{astronaut}}: <strong>{{mission}}</strong>
      <button
        (click)="confirm()"
        [disabled]="!announced || confirmed">
        Confirm
      </button>
    </p>
  `
})

export class AstronautComponent implements OnDestroy {
  @Input() astronaut: string;
  mission = '<no mission announced>';
  confirmed = false;
  announced = false;
  subscription: Subscription;

  constructor(private missionService: MissionService) {
    this.subscription = missionService.missionAnnounced$.subscribe(
      mission => {
        this.mission = mission;
        this.announced = true;
        this.confirmed = false;
    });
  }

  confirm() {
    this.confirmed = true;
    this.missionService.confirmMission(this.astronaut);
  }

  ngOnDestroy() {
    //prevent memory leak when component destroyed
    this.subscription.unsubscribe();
  }
}

En cas de désabonnement est nécessaire, l'opérateur suivants pour observable pipe méthode peut être utilisée

import { Observable, Subject } from 'rxjs';
import { takeUntil } from 'rxjs/operators';
import { OnDestroy } from '@angular/core';

export const takeUntilDestroyed = (componentInstance: OnDestroy) => <T>(observable: Observable<T>) => {
  const subjectPropertyName = '__takeUntilDestroySubject__';
  const originalOnDestroy = componentInstance.ngOnDestroy;
  const componentSubject = componentInstance[subjectPropertyName] as Subject<any> || new Subject();

  componentInstance.ngOnDestroy = (...args) => {
    originalOnDestroy.apply(componentInstance, args);
    componentSubject.next(true);
    componentSubject.complete();
  };

  return observable.pipe(takeUntil<T>(componentSubject));
};

il peut être utilisé comme ceci:

import { Component, OnDestroy, OnInit } from '@angular/core';
import { Observable } from 'rxjs';

@Component({ template: '<div></div>' })
export class SomeComponent implements OnInit, OnDestroy {

  ngOnInit(): void {
    const observable = Observable.create(observer => {
      observer.next('Hello');
    });

    observable
      .pipe(takeUntilDestroyed(this))
      .subscribe(val => console.log(val));
  }

  ngOnDestroy(): void {
  }
}

L'opérateur enveloppements ngOnDestroy méthode de composant.

Important: l'opérateur doit être le dernier observables de la pipe.

Pour la manipulation abonnement j'ai utiliser un "Unsubscriber" de la classe.

Ici est la Unsubscriber Classe.

export class Unsubscriber implements OnDestroy {
  private subscriptions: Subscription[] = [];

  addSubscription(subscription: Subscription | Subscription[]) {
    if (Array.isArray(subscription)) {
      this.subscriptions.push(...subscription);
    } else {
      this.subscriptions.push(subscription);
    }
  }

  unsubscribe() {
    this.subscriptions
      .filter(subscription => subscription)
      .forEach(subscription => {
        subscription.unsubscribe();
      });
  }

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

Et Vous pouvez utiliser cette classe dans un composant /Service /Effet etc.

Exemple:

class SampleComponent extends Unsubscriber {
    constructor () {
        super();
    }

    this.addSubscription(subscription);
}