Angular / RxJs Kiedy powinienem zrezygnować z subskrypcji "subskrypcja"

Nie musisz mieć kilku subskrypcji i wypisać się ręcznie. Użyj RxJS.Subject i takeUntil combo do obsługi abonamentów jak boss:

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

Alternatywne podejście , które zostało zaproponowane przez @acumartini w komentarzach , wykorzystuje takeWhilezamiast takuntil. Możesz go preferować, ale pamiętaj, że w ten sposób Twoje obserwowalne wykonanie nie zostanie anulowane na ngDestroy twojego komponentu (np. korzystanie z obliczeń lub oczekiwanie na dane z serwera). Metoda, która opiera się na takeUntil , nie ma tej wady i prowadzi do natychmiastowego anulowania wniosku. podziękowania dla @ AlexChe za szczegółowe wyjaśnienie w komentarzach .

Oto kod:

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

Klasa subskrypcji ma ciekawą funkcję:

Reprezentuje zasoby jednorazowe, takie jak wykonanie obserwowalnego. Subskrypcja ma jedną ważną metodę, anulowanie subskrypcji, która nie wymaga żadnego argumentu i po prostu usuwa zasoby posiadane przez subskrypcję.
ponadto subskrypcje mogą być grupowane za pomocą metody add (), która dołączy subskrypcję podrzędną do bieżącej subskrypcji. Gdy subskrypcja zostanie anulowana, wszystkie jej dzieci (i jego wnuki) zostaną również wypisane.

Możesz utworzyć zbiorczy obiekt subskrypcji, który grupuje wszystkie subskrypcje. Można to zrobić, tworząc pustą subskrypcję i dodając do niej subskrypcje za pomocą metody add(). Gdy komponent zostanie zniszczony, wystarczy zrezygnować z subskrypcji zbiorczej.

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

To zależy. Jeśli wywołując someObservable.subscribe(), zaczniesz zatrzymywać jakiś zasób, który musi zostać ręcznie uwolniony po zakończeniu cyklu życia komponentu, powinieneś wywołać theSubscription.unsubscribe(), aby zapobiec wyciekowi pamięci.

getHero() zwraca wynik http.get(). Jeśli spojrzysz w kątowy 2 kod źródłowy, http.get() tworzy dwa słuchacze zdarzeń:

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

I dzwoniąc unsubscribe(), możesz anulować żądanie, jak również słuchacze:

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

Zauważ, że _xhr jest specyficzna dla platformy, ale myślę, że można bezpiecznie założyć, że jest to XMLHttpRequest() w Twoim przypadku.

Co do twojej drugiej przykład, zależy to od implementacji params. Od dziś oficjalny przewodnik angular nie pokazuje już rezygnacji z params. Zajrzałem do src ponownie i okazało się, że params jest tylko BehaviorSubject . Ponieważ nie użyto detektorów zdarzeń ani timerów ani nie stworzono zmiennych globalnych, należy bezpiecznie pominąć unsubscribe().

Reasumując twoje pytanie jest takie, że zawsze dzwoń unsubscribe() jako strażnik przed wyciekiem pamięci, chyba że jesteś pewien, że wykonanie z obserwowalnych nie tworzy zmiennych globalnych, nie dodaje detektorów zdarzeń, nie ustawia timerów ani nie robi niczego innego, co powoduje wycieki pamięci.

W razie wątpliwości, przyjrzyj się implementacji tego obserwowalnego. Jeśli obserwowalny zapisał jakąś logikę do swojej unsubscribe(), która jest zwykle funkcją zwracaną przez konstruktor, to masz dobry powód, aby poważnie rozważyć wywołanie unsubscribe().

Niektóre z najlepszych praktyk dotyczących zapisów obserwowalnych wewnątrz elementów kątowych:

Cytat z Routing & Navigation

Kiedy subskrybujesz komponent obserwowalny w komponencie, prawie zawsze możesz zrezygnować z subskrypcji, gdy komponent zostanie zniszczony.

Istnieje kilka wyjątkowych obserwacji, gdzie nie jest to konieczne. Do wyjątków należą

Aktywowany i jego obserwatory są izolowane od samego routera. Router niszczy kierowany komponent, gdy nie jest już potrzebny, a wtryskiwany aktywator umiera wraz z nim.

Nie krępuj się i tak zrezygnować z subskrypcji. Jest nieszkodliwa i nigdy nie jest złą praktyką.

I odpowiadając na następujące linki:

• (1) Czy powinienem zrezygnować z usługi Angular 2 http Observables?
• (2) czy konieczne jest wypisanie się z obserwatoriów utworzonych przez Http metody?
• (3) RxJS: Nie wypisuj się]}
• (4) w ten sposób można uzyskać dostęp do wszystkich obserwowanych obiektów.]}
• (5) dokumentacja do wypisania się z RxJS
• (6) Nie Jest to możliwe, ponieważ nie ma szans na wycieki pamięci.]}
• (7) Czy musimy zrezygnować z subskrypcji observable, że kończy / błędy-out?
• (8) komentarz do http obserwowalne

Zebrałem kilka najlepszych praktyk dotyczących zapisów obserwowalnych wewnątrz elementów kątowych, aby podzielić się z wami: {]}

• http obserwowalne wypisanie się jest warunkowe i powinniśmy rozważyć efekty wywołania zwrotnego "subscribe" uruchamianego po zniszczeniu komponentu indywidualnie. Wiemy, że angular usuwa i czyści http obserwowalny sam (1), (2). Choć to prawda z perspektywa zasobów opowiada tylko połowę historii. Załóżmy, że mówimy o bezpośrednim wywołaniu http z wewnątrz komponentu, a odpowiedź http trwała dłużej niż potrzeba, więc użytkownik zamknął komponent. Procedura obsługi subscribe() będzie nadal wywoływana, nawet jeśli komponent zostanie zamknięty i zniszczony. Może to mieć niepożądane skutki uboczne i w gorszych scenariuszach pozostawić stan aplikacji uszkodzony. Może również powodować wyjątki, jeśli kod w wywołaniu zwrotnym próbuje wywołać coś, co właśnie zostało wyrzucony. Jednak w tym samym czasie czasami są pożądane. Powiedzmy, że tworzysz klienta poczty e-mail i uruchamiasz dźwięk, gdy wiadomość e-mail zostanie wysłana - cóż, nadal chcesz, aby to nastąpiło, nawet jeśli komponent jest zamknięty (8).
• nie ma potrzeby wypisywania się z obserwowalnych, które są kompletne lub błędne. Jednak nie ma w tym nic złego(7).
• użyj AsyncPipe jak najwięcej, ponieważ automatycznie wypisuje się z obserwowalnego na zniszczenie komponentów.
• Anuluj subskrypcję z ActivatedRoute obserwabli, takich jak route.params, jeśli są subskrybowane wewnątrz zagnieżdżonego (dodanego wewnątrz tpl za pomocą selektora komponentów) lub dynamicznego komponentu, ponieważ mogą być subskrybowane wiele razy, dopóki komponent macierzysty/host istnieje. Nie ma potrzeby wypisywania się z nich w innych scenariuszach, jak wspomniano w cytacie powyżej z Routing & Navigation docs.
• wypisanie się z globalnych obserwabli współdzielonych między komponentami, które są odsłonięte przez kąt usługi, na przykład, ponieważ mogą być subskrybowane wiele razy tak długo, jak długo komponent jest inicjowany.
• nie ma potrzeby wypisywania się z wewnętrznych obserwowalności usługi o zasięgu aplikacji, ponieważ ta usługa nigdy nie zostanie zniszczona, chyba że cała aplikacja zostanie zniszczona, nie ma prawdziwego powodu, aby z niej zrezygnować i nie ma szans na wycieki pamięci. (6).
  
  Uwaga: W odniesieniu do usług scoped, tj. dostawców komponentów, są one niszczone, gdy komponent jest zniszczony. W takim przypadku, jeśli SUBSKRYBUJEMY jakiekolwiek możliwe do zaobserwowania wewnątrz tego dostawcy, powinniśmy rozważyć wypisanie się z niego za pomocą OnDestroy hook cyklu życia, który zostanie wywołany, gdy usługa zostanie zniszczona, zgodnie z dokumentami.
• użyj abstrakcyjnej techniki, aby uniknąć bałaganu w kodzie, który może być spowodowany anulowaniem napisów. Możesz zarządzać swoimi subskrypcjami za pomocą takeUntil (3) możesz też użyć tego npm pakiet wymieniony w (4) Najprostszy sposób wypisania się z obserwatoriów w Angular .
• zawsze wypisuj się z FormGroup obserwatoriów takich jak form.valueChanges i form.statusChanges
• zawsze wypisuj się z obserwatoriów Renderer2 usługi jak renderer2.listen
• Anuluj subskrypcję z każdej obserwowalnej innej jako zabezpieczenie przed wyciekiem pamięci, dopóki Angular Docs nie powie nam, które obserwowalne obiekty nie są konieczne do anulowania subskrypcji(problem z zaznaczeniem: (5) Dokumentacja dla Rxjs anulowanie subskrypcji (Open)).
• Bonus: Zawsze użyj kątowych sposobów wiązania zdarzeń, takich jak HostListener, ponieważ angular dobrze dba o usunięcie słuchaczy zdarzeń w razie potrzeby i zapobiega potencjalnemu wyciekowi pamięci z powodu wiązań zdarzeń.

Ostatnia wskazówka: Jeśli nie wiesz, czy obserwowalny jest automatycznie anulowany / zakończony, dodaj callback complete do subscribe(...) i sprawdź, czy zostanie wywołany po zniszczeniu komponentu.

Oficjalna dokumentacja Angular 2 zawiera wyjaśnienie, kiedy zrezygnować z subskrypcji i kiedy można ją bezpiecznie zignorować. Zobacz ten link:

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

Poszukaj akapitu z nagłówkiem rodzic i dzieci komunikują się za pośrednictwem usługi , a następnie niebieskie pole:

Zauważ, że rejestrujemy subskrypcję i rezygnujemy z subskrypcji, gdy AstronautComponent jest zniszczony. To zabezpieczenie przed wyciekiem pamięci. Nie ma rzeczywistego ryzyka w tej aplikacji, ponieważ czas życia Astronautskładnik jest taki sam jak czas życia samej aplikacji. Nie zawsze byłoby to prawdą w bardziej złożonej aplikacji.

Nie dodajemy tego strażnika do komponentu MissionControlComponent, ponieważ jako rodzic kontroluje czas życia usługi Mission.

Mam nadzieję, że to ci pomoże.

Ponieważ rozwiązanie seangwrighta (Edit 3) wydaje się bardzo przydatne, uznałem również, że upierdliwe jest spakowanie tej funkcji do komponentu bazowego i podpowiedzenie innym członkom zespołu projektu, aby pamiętali o wywołaniu super () na ngOnDestroy, aby aktywować tę funkcję.

Ta odpowiedź daje sposób na uwolnienie od super call i uczynienie "componentDestroyed$" rdzeniem komponentu bazowego.

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

I wtedy możesz swobodnie korzystać z tej funkcji na przykład:

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

}

Na podstawie: Wykorzystanie dziedziczenia klas do łączenia się z cyklem życia 2 składowych

Inne ogólne podejście:

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
  }

}

I użycie:

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

Oficjalna odpowiedź Edit # 3 (i odmiany) działa dobrze, ale to, co mnie denerwuje, to "zamulanie" logiki biznesowej wokół obserwowalnej subskrypcji.

Oto inne podejście przy użyciu opakowań.

Warning: Kod eksperymentalny

Plik subscribeAndGuard.ts {[18] } służy do tworzenia nowego obserwowalnego rozszerzenia do wrap .subscribe() i wewnątrz niego do wrap ngOnDestroy().
Użycie jest takie samo jak .subscribe(), z wyjątkiem dodatkowego pierwszego parametru odniesienie do komponentu.

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

Oto komponent z dwiema subskrypcjami, jedną z opakowaniem i jedną bez. Jedynym zastrzeżeniem jest to, że musi zaimplementować OnDestroy (z pustym ciałem w razie potrzeby), w przeciwnym razie Angular nie wie, aby wywołać wersję zawiniętą.

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

A demo plunker is here

Uwaga dodatkowa: Re Edit 3 - 'oficjalne' rozwiązanie, można to uprościć używając takeWhile () zamiast takeUntil () przed subskrypcji, A prosty boolean, a nie inny obserwowalny w 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;
  }
}

Lubię dwie ostatnie odpowiedzi, ale doświadczyłem problemu, jeśli podklasa odwołuje się "this" w ngOnDestroy.

Zmodyfikowałem go tak, i wygląda na to, że rozwiązał ten problem.

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

Podążając za odpowiedzią @seangwright , napisałem klasę abstrakcyjną, która obsługuje "nieskończone" subskrypcje obserwowalne w komponentach:

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

Aby go użyć, wystarczy rozszerzyć go w składniku kątowym i wywołać metodę subscribe() w następujący sposób:

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

Akceptuje również błąd i wykonuje wywołania zwrotne jak zwykle, obiekt obserwatora, lub w ogóle nie wywołuje. Pamiętaj, aby wywołać super.ngOnDestroy(), Jeśli implementujesz tę metodę również w komponencie potomnym.

Znajdź tutaj dodatkowe odniesienie Ben Lesh: RxJS: Don ' t Unsubscribe .

I tried seangwright ' s solution (Edit 3)

To nie działa dla obserwowalnych, które są tworzone przez timer lub interwał.

Jednak udało mi się to przy użyciu innego podejścia:

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

Zazwyczaj musisz zrezygnować z subskrypcji, gdy komponenty zostaną zniszczone, ale Angular będzie obsługiwać ją coraz bardziej, na przykład w nowej, mniejszej wersji Angular4, mają tę sekcję do routingu wypisania się:

Czy musisz zrezygnować z subskrypcji?

jak opisano w ActivatedRoute: punkt kompleksowej obsługi dla sekcji informacji o trasie Strona routingu i nawigacji, Router zarządza obserwowanymi zapewnia i lokalizuje subskrypcje. Na subskrypcje są czyszczenie po zniszczeniu komponentu, chroniąc przed pamięcią przecieki, więc nie musisz wypisywać się z paramapy trasy Obserwowalne.

Również poniższy przykład jest dobrym przykładem z Angular, aby utworzyć komponent i zniszczyć go po, spójrz jak komponent implementuje OnDestroy, jeśli potrzebujesz onInit, możesz również zaimplementować go w swoim komponencie, jak implementuje 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();
  }
}

Kolejnym krótkim dodatkiem do wyżej wymienionych sytuacji jest:

• zawsze Anuluj subskrypcję, gdy nowe wartości w subskrybowanym strumieniu nie są już wymagane lub nie mają znaczenia, spowoduje to znacznie mniejszą liczbę wyzwalaczy i zwiększenie wydajności w kilku przypadkach. Przypadki, takie jak komponenty, w których subskrybowane dane/zdarzenie już nie istnieje lub wymagana jest nowa subskrypcja zupełnie nowego strumienia (odświeżanie itp.) jest dobrym przykładem rezygnacji z subskrypcji.