Как перенести подписку на стрим из метода, вызываемого юзером, в ngOnInit()?

Question

[alexbog90]

Слышал мнение, что плохая практика - подписываться на стрим внутри метода, который вызывается, скажем, по клику на кнопку.

public deleteShredder(shredderId: string): void {
	this._shredService.deleteShredder(shredderId).pipe(
		switchMap(() => this._shredService.refreshShredderList()),
	).subscribe();
}

Например, в этом случае, я конечно отпишусь от подписки в onDestroy(), но как сделать код более чистым, чтобы .subscribe() был в OnInit()?

Answer 1

[Антон Швец]

Слышал мнение, что плохая практика - подписываться на стрим внутри метода, который вызывается, скажем, по клику на кнопку.

Первый раз слышу.

Но если угодно.

deleteShredderEvt = new Subject();

ngOnInit() {
  this.deleteShredderEvt.pipe(
    switchMap((shredderId) => this._shredService.deleteShredder(shredderId))
  )
    .subscribe();
}

<button (click)="deleteShredderEvt.next(shredderId)"></button>

че нить такое. Вместо подписки можно инициировать событие, а в он-инит подписаться на цепочку, начинающуюся с этого события

Answer 2

[Demian Smith]

Старайтесь свести работу с обзёрваблами к подписке на них через asyncPipe. В таком случае ангуляр будет менеджить подписки/отписки за вас.

Как это корректно делать не подскажу, потому что сам пришел к этому слишком поздно к концу двухлетнего проекта и уже полтара года как не сталкивался с ангуляром. Но на вид это возможно. Имхо нужно сохранять голову на плечах и не пытаться вывернуться с RxJS во что бы то ни стало потому что через месяц самому будет непонятно как это работает.

Хорошее правило работы с RxJS - стараться откладывать вызов subscribe на потом. Код будет гибче если ваши методы не вызвают subsctibe, а возвращают observable. А подписка на сам observable происходит где-то в другом месте (например в том же asyncPipe). Ну или в том месте, где уже просто никак без подписки :-) Многие начинающие ангулярщики боятся RxJS как огня и подписываются на обзёрвблы при первой возможности, а дальше менеджат код в привычном инперативном виде. Такой стиль кодирования обычно заканчивается жалобами на сам фреймворк (мол он ничего не умеет).