Angular / RxJs когда я должен отказаться от подписки на " подписку`

вам не нужно иметь кучу подписок и отписаться вручную. Использовать RxJS.Тема и takeUntil combo для обработки подписок, как босс:

import {Subject} from "rxjs/Subject";

@Component(
    {
        moduleId: __moduleName,
        selector: 'my-view',
        templateUrl: '../views/view-route.view.html',
    }
)
export class ViewRouteComponent implements OnDestroy
{
    componentDestroyed$: Subject<boolean> = new Subject();

    constructor(protected titleService: TitleService)
    {
        this.titleService.emitter1$
            .takeUntil(this.componentDestroyed$)
            .subscribe(
            (data: any) =>
            {
                // ... do something 1
            }
        );

        this.titleService.emitter2$
            .takeUntil(this.componentDestroyed$)
            .subscribe(
            (data: any) =>
            {
                // ... do something 2
            }
        );

        // ...

        this.titleService.emitterN$
            .takeUntil(this.componentDestroyed$)
            .subscribe(
            (data: any) =>
            {
                // ... do something N
            }
        );
    }

    ngOnDestroy()
    {
        this.componentDestroyed$.next(true);
        this.componentDestroyed$.complete();
    }
}

альтернативный подход, который предложил @acumartini в комментариях, используется takeWhile вместо takeUntil. Вы можете предпочесть это, но имейте в виду, что таким образом ваше наблюдаемое исполнение не будет отменено ngDestroy вашего компонента (например, когда вы делаете трудоемкие вычисления или ждете данных с сервера). Метод, который основан на takeUntil, не имеет этого недостатка и ведет к немедленной отмене запроса. спасибо @AlexChe за подробное объяснение в комментариях.

Итак, вот код:

@Component(
    {
        moduleId: __moduleName,
        selector: 'my-view',
        templateUrl: '../views/view-route.view.html',
    }
)
export class ViewRouteComponent implements OnDestroy
{
    alive: boolean = true;

    constructor(protected titleService: TitleService)
    {
        this.titleService.emitter1$
            .takeWhile(() => this.alive)
            .subscribe(
            (data: any) =>
            {
                // ... do something 1
            }
        );

        this.titleService.emitter2$
            .takeWhile(() => this.alive)
            .subscribe(
            (data: any) =>
            {
                // ... do something 2
            }
        );

        // ...

        this.titleService.emitterN$
            .takeWhile(() => this.alive)
            .subscribe(
            (data: any) =>
            {
                // ... do something N
            }
        );
    }

    // Probably, this.alive = false MAY not be required here, because
    // if this.alive === undefined, takeWhile will stop. I
    // will check it as soon, as I have time.
    ngOnDestroy()
    {
        this.alive = false;
    }
}

класс подписки имеет интересную особенность:

представляет собой одноразовый ресурс, такой как выполнение наблюдаемого. Подписка имеет один важный метод, unsubscribe, который не принимает аргументов и просто утилизирует ресурс, удерживаемый подпиской.
кроме того, подписки могут быть сгруппированы вместе с помощью метода add (), который присоединит дочернюю подписку к текущей подписке. Когда подписка отписана, все его дети (и внуки) также будут отписаны.

вы можете создать объект aggregate Subscription, который группирует все ваши подписки. Вы делаете это, создавая пустую подписку и добавляя к ней подписки, используя ее add() метод. Когда ваш компонент уничтожен, вам нужно только отменить подписку aggregate.

@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();
  }
}

это зависит. Если позвонив someObservable.subscribe(), вы начинаете удерживать какой-то ресурс, который должен быть освобожден вручную, когда жизненный цикл вашего компонента закончится, тогда вы должны вызвать theSubscription.unsubscribe() для предотвращения утечек памяти.

давайте подробнее рассмотрим ваши примеры:

getHero() возвращает результат http.get(). Если вы посмотрите в угловое 2 исходный код, http.get() создает два прослушивателя событий:

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

и unsubscribe(), вы можете отменить запрос, а также слушателей:

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

отметим, что _xhr является специфичной платформой, но я думаю, что можно с уверенностью предположить, что это XMLHttpRequest() в вашем случае.

как правило, это достаточно доказательств, чтобы оправдать руководство unsubscribe() звонок. Но согласно этому WHATWG spec на XMLHttpRequest() подлежит сбору мусора, как только он" сделан", даже если к нему прикреплены прослушиватели событий. Поэтому я думаю, что именно поэтому angular 2 официальный гид опускает unsubscribe() и позволяет GC очистить слушателей.

Что касается вашего второго примера, это зависит от реализации params. На сегодняшний день официальное руководство angular больше не показывает отписку от params. Я заглянул в src снова и обнаружил, что params это просто a BehaviorSubject. Поскольку прослушиватели событий или таймеры не использовались и глобальные переменные не создавались, следует с уверенностью опустить unsubscribe().

нижняя строка к вашему вопрос в том, что всегда звоните unsubscribe() в качестве защиты от утечки памяти, если вы не уверены, что выполнение наблюдаемого не создает глобальных переменных, добавьте прослушиватели событий, установите таймеры или сделайте что-нибудь еще, что приводит к утечкам памяти.

когда вы сомневаетесь, посмотрите на реализацию этого наблюдаемого. Если наблюдаемое записало некоторую чистую логику в его unsubscribe(), который обычно является функцией, возвращаемой конструктором, тогда у вас есть веские основания серьезно рассмотреть возможность вызова unsubscribe().

некоторые из лучших практик относительно observables отписки внутри угловых компонентов:

цитата Routing & Navigation

при подписке на наблюдаемое в компоненте вы почти всегда отменяете подписку, когда компонент уничтожается.

есть несколько исключительных наблюдаемых, где это не обязательно. В ActivatedRoute наблюдаемых среди исключений.

ActivatedRoute и его наблюдаемые изолированы от самого маршрутизатора. Маршрутизатор уничтожает маршрутизируемый компонент, когда он больше не нужен, и введенный ActivatedRoute умирает с ним.

не стесняйтесь отказаться от подписки в любом случае. Это безобидная и никогда не плохая практика.

и в ответ на следующие ссылки:

• (1) должен ли я отказаться от подписки на Angular 2 Http Observables?
• (2) нужно ли отказатся от наблюдаемых создается HTTP-методов?
• (3) RxJS: не отказывайтесь от подписки
• (4) самый простой способ отписаться от наблюдаемых в Angular
• (5) документация для RxJS отписка
• (6) отписка в сервисе бессмысленна, так как нет никаких шансов на утечку памяти
• (7) Do нам нужно отписаться от observable который завершает/errors-out?
• (8) комментарий к http наблюдаемых

я собрал некоторые из лучших практик в отношении observables отписки внутри угловых компонентов, чтобы поделиться с вами:

• http наблюдаемая отмена подписки является условной, и мы должны рассмотреть последствия запуска обратного вызова "subscribe" после уничтожения компонента на случая к случаю. Мы знаем, что angular отписывается и очищает http наблюдаемой себя (1), (2). Хотя это верно с точки зрения ресурсов, это говорит только о половине истории. Допустим, мы говорим о прямом вызове http изнутри компонента и http ответ занял больше времени, чем нужно, поэтому пользователь закрыл компонент. The subscribe() обработчик будет вызываться даже если компонент закрыт и разрушен. Это может быть нежелательные побочные эффекты и в худших сценариях оставляют состояние приложения нарушенным. Это также может вызвать исключения, если код в обратном вызове пытается вызвать что-то, что только что было удалено. Однако в то же время иногда они нужные. Например, предположим, вы создаете почтовый клиент, и вы запускаете звук, когда электронная почта отправляется - ну, вы все равно хотите, чтобы это произошло, даже если компонент закрыт (8).
• отписываться не нужно наблюдаемые, которые полны или ошибочны. Тем не менее, нет никакого вреда в этом(7).
• использовать AsyncPipe как можно больше, потому что он автоматически отписывается от наблюдаемого при уничтожении компонента.
• отписаться от ActivatedRoute наблюдаемых как route.params если они подписаны внутри вложенного (добавленного внутри tpl с селектором компонентов) или динамического компонента, поскольку они могут быть подписаны много раз, пока существует Родительский/хост-компонент. Нет нужно отписаться от них в других сценариях, как указано в цитате выше от Routing & Navigation документы.
• Отменить подписку на глобальные наблюдаемые, общие для компонентов, которые предоставляются через угловой сервис, например, поскольку они могут быть подписаны несколько раз, пока компонент инициализирован.
• нет необходимости отписываться от внутренних наблюдаемых служб приложения, поскольку эта служба никогда не уничтожается, если только весь ваш приложение get уничтожено, нет реальной причины отписываться от него, и нет никаких шансов на утечку памяти. (6).
  
  Примечание: что касается сферы услуг, i.e поставщики компонентов, они уничтожаются при уничтожении компонента. В этом случае, если мы подписываемся на любой наблюдаемый внутри этого провайдера, мы должны рассмотреть возможность отмены подписки с помощью OnDestroy lifecycle hook, который будет вызываться, когда служба уничтожен, согласно документам.
• используйте абстрактный метод, чтобы избежать любого беспорядка кода, который может быть результатом отписки. Вы можете управлять подписками с помощью takeUntil (3) или вы можете использовать этот npm пакета упомянутые в (4) Самый простой способ отписаться от наблюдаемых в Angular.
• всегда отписаться от FormGroup наблюдаемых как form.valueChanges и form.statusChanges
• обязательно отпишусь из наблюдаемых Renderer2 сервис как renderer2.listen
• отписаться от каждого наблюдаемого else в качестве шага защиты от утечки памяти, пока угловые документы явно не скажут нам, какие наблюдаемые не нужны для отписки (Проверьте проблему:(5) документация для RxJS Unsubscribing (Open)).
• бонус: всегда используйте угловые способы привязки событий, как HostListener as angular хорошо заботится об удалении прослушивателей событий, если это необходимо, и предотвращает любую потенциальную память утечка из-за Привязок событий.

хороший последний совет: если вы не знаете, если observable автоматически отменяется/завершается или нет, добавьте complete обратный вызов subscribe(...) и проверьте, вызывается ли он при уничтожении компонента.

Angular 2 официальная документация дает объяснение, когда отказаться от подписки и когда его можно безопасно игнорировать. Посмотрите на эту ссылку:

https://angular.io/docs/ts/latest/cookbook/component-communication.html#!#bidirectional-service

найдите абзац с заголовком родители и дети общаются через службу и затем синяя коробка:

обратите внимание, что мы фиксируем подписка и отпишусь, когда AstronautComponent разрушается. Это шаг защиты от утечки памяти. В этом приложении нет фактического риска, потому что срок службы AstronautComponent такой же, как и срок службы самого приложения. Это не всегда верно в более сложном применении.

мы не добавляем этот предохранитель к MissionControlComponent, потому что, как родитель, он контролирует время жизни MissionService.

Я надеюсь, это поможет вам.

поскольку решение seangwright (Edit 3) кажется очень полезным, я также нашел боль, чтобы упаковать эту функцию в базовый компонент и намекнуть другим товарищам по команде проекта не забыть позвонить super () на ngOnDestroy, чтобы активировать эту функцию.

этот ответ предоставляет способ освободить от супер-вызова и сделать "componentDestroyed$" ядром базового компонента.

class BaseClass {
    protected componentDestroyed$: Subject<void> = new Subject<void>();
    constructor() {

        /// wrap the ngOnDestroy to be an Observable. and set free from calling super() on ngOnDestroy.
        let _$ = this.ngOnDestroy;
        this.ngOnDestroy = () => {
            this.componentDestroyed$.next();
            this.componentDestroyed$.complete();
            _$();
        }
    }

    /// placeholder of ngOnDestroy. no need to do super() call of extended class.
    ngOnDestroy() {}
}

и затем вы можете использовать эту функцию свободно, например:

@Component({
    selector: 'my-thing',
    templateUrl: './my-thing.component.html'
})
export class MyThingComponent extends BaseClass implements OnInit, OnDestroy {
    constructor(
        private myThingService: MyThingService,
    ) { super(); }

    ngOnInit() {
        this.myThingService.getThings()
            .takeUntil(this.componentDestroyed$)
            .subscribe(things => console.log(things));
    }

    /// optional. not a requirement to implement OnDestroy
    ngOnDestroy() {
        console.log('everything works as intended with or without super call');
    }

}

основывается на : использование наследования класса для подключения к угловому жизненному циклу компонента 2

еще один общий подход:

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
  }

}

и использовать :

@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));
    }
}

официальный ответ Edit #3 (и варианты) работает хорошо, но то, что меня заводит, - это "запутывание" бизнес-логики вокруг наблюдаемой подписки.

вот еще один подход с использованием фантиков.

Warining: экспериментальный код

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;
  }
}

вот компонент с двумя подписками, один с оболочкой и один без. Единственное предостережение-это необходимо реализовать OnDestroy (при желании с пустым телом), в противном случае Angular не знает, как вызвать обернутую версию.

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');
  }
}

демо-plunker составляет здесь

дополнительно: Re Edit 3 - "Официальный" Решение, это можно упростить, используя takeWhile() вместо takeUntil () перед подписками и простое логическое, а не другое наблюдаемое в 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;
  }
}

мне нравятся последние два ответа, но у меня возникла проблема, если подкласс ссылается "this" на ngOnDestroy.

Я изменил его, чтобы быть этим, и похоже, что он решил эту проблему.

export abstract class BaseComponent implements OnDestroy {
    protected componentDestroyed$: Subject<boolean>;
    constructor() {
        this.componentDestroyed$ = new Subject<boolean>();
        let f = this.ngOnDestroy;
        this.ngOnDestroy = function()  {
            // without this I was getting an error if the subclass had
            // this.blah() in ngOnDestroy
            f.bind(this)();
            this.componentDestroyed$.next(true);
            this.componentDestroyed$.complete();
        };
    }
    /// placeholder of ngOnDestroy. no need to do super() call of extended class.
    ngOnDestroy() {}
}

после ответа на @seangwright, Я написал абстрактный класс, который обрабатывает подписки "бесконечных" наблюдаемых в компонентах:

import { OnDestroy } from '@angular/core';
import { Subscription } from 'rxjs/Subscription';
import { Subject } from 'rxjs/Subject';
import { Observable } from 'rxjs/Observable';
import { PartialObserver } from 'rxjs/Observer';

export abstract class InfiniteSubscriberComponent implements OnDestroy {
  private onDestroySource: Subject<any> = new Subject();

  constructor() {}

  subscribe(observable: Observable<any>): Subscription;

  subscribe(
    observable: Observable<any>,
    observer: PartialObserver<any>
  ): Subscription;

  subscribe(
    observable: Observable<any>,
    next?: (value: any) => void,
    error?: (error: any) => void,
    complete?: () => void
  ): Subscription;

  subscribe(observable: Observable<any>, ...subscribeArgs): Subscription {
    return observable
      .takeUntil(this.onDestroySource)
      .subscribe(...subscribeArgs);
  }

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

чтобы использовать его, просто расширьте его в своем угловом компоненте и вызовите subscribe() метод следующим образом:

this.subscribe(someObservable, data => doSomething());

Он также принимает ошибку и полные обратные вызовы, как обычно, объект наблюдателя или не обратные вызовы вообще. Не забудьте позвонить super.ngOnDestroy() Если вы также реализуете этот метод в дочернем деталь.

найти здесь дополнительную ссылку Бен Леша:RxJS: не отказывайтесь от подписки.

я попробовал решение seangwright (Edit 3)

Это не работает для наблюдаемого, созданного таймером или интервалом.

однако я заставил его работать, используя другой подход:

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();
   }
 }
}

обычно вам нужно отписаться, когда компоненты будут уничтожены, но Angular будет обрабатывать его все больше и больше, например, в новой минорной версии Angular4, у них есть этот раздел для маршрутизации отписаться:

вам нужно отказаться от подписки?

как описано в ActivatedRoute: один-стоп-магазин для раздела информации о маршруте Страница маршрутизации и навигации, маршрутизатор управляет наблюдаемыми обеспечивает и локализует подписки. Подписки очищенный вверх когда компонент разрушен, защищающ против памяти утечки, поэтому вам не нужно отписываться от маршрута paramMap Заметный.

также приведенный ниже пример является хорошим примером из Angular для создания компонента и его уничтожения после, посмотрите, как компонент реализует OnDestroy, если вам нужен onInit, вы также можете реализовать его в своем компоненте, например implements 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();
  }
}

еще одно короткое дополнение к вышеупомянутым ситуациям:

• всегда отменяйте подписку, когда новые значения в подписанном потоке больше не требуются или не имеют значения, это приведет к уменьшению количества триггеров и повышению производительности в нескольких случаях. Такие случаи, как компоненты, где подписанные данные / событие больше не существует или требуется новая подписка на весь Новый Поток (обновить и т. д.) является хорошим примером для отмены подписки.