Когда я должен создать новую подписку для определенного побочного эффекта?

На прошлой неделе я ответил на вопрос RxJS, где я вступил в дискуссию с другим членом сообщества на тему : «Должен ли я создать подписку для каждого конкретного побочного эффекта или я должен попытаться минимизировать подписки в целом?» Я хочу знать, какую методологию использовать с точки зрения полного реактивного подхода к применению или когда переключаться с одного на другой. Это поможет мне и, возможно, другим избежать ненужных дискуссий.

Информация о настройке

• Все примеры в TypeScript
• Чтобы лучше сосредоточиться на вопросе, не использовать жизненные циклы / конструкторы для подписок и держать в рамках не связанными
  • Представьте себе: подписки добавляются в init конструктора / жизненного цикла
  • Представьте себе: отмена подписки осуществляется в жизненном цикле уничтожения

Что такое побочный эффект (угловой образец)

• Обновление / ввод в пользовательском интерфейсе (например value$ | async)
• Выход / восходящий поток компонента (например @Output event = event$)
• Взаимодействие между различными службами в разных иерархиях

Примерный вариант использования:

• Две функции: foo: () => void; bar: (arg: any) => void
• Две исходные наблюдаемые: http$: Observable<any>; click$: Observable<void>
• fooвызывается после того, как http$выпустил и не нуждается в значении
• barвызывается после click$эмиссии, но нуждается в текущем значенииhttp$

Случай: создать подписку для каждого конкретного побочного эффекта

const foo$ = http$.pipe(
  mapTo(void 0)
);

const bar$ = http$.pipe(
  switchMap(httpValue => click$.pipe(
    mapTo(httpValue)
  )
);

foo$.subscribe(foo);
bar$.subscribe(bar);

Дело: Минимизировать подписки в целом

http$.pipe(
  tap(() => foo()),
  switchMap(httpValue => click$.pipe(
    mapTo(httpValue )
  )
).subscribe(bar);

Мое собственное мнение вкратце

Я могу понять тот факт, что подписки вначале усложняют Rx-ландшафты, потому что вы должны думать о том, как подписчики, например, должны влиять на канал или нет (поделиться своими наблюдаемыми или нет). Но чем больше вы разделяете свой код (чем больше вы сосредотачиваетесь: что происходит, когда), тем легче поддерживать (тестировать, отлаживать, обновлять) ваш код в будущем. Имея это в виду, я всегда создаю один наблюдаемый источник и одну подписку для любого побочного эффекта в моем коде. Если два или более моих побочных эффектов вызваны одним и тем же наблюдаемым источником, то я делюсь своим наблюдаемым и подписываюсь на каждый побочный эффект индивидуально, потому что он может иметь разные жизненные циклы.

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

Однако существуют ситуации, в которых может быть полезно создать подписку, которая не является строго «необходимой»:

Пример исключения - повторное использование наблюдаемых в одном шаблоне

Глядя на ваш первый пример:

// Component:

this.value$ = this.store$.pipe(select(selectValue));

// Template:

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

Если значение $ используется только один раз в шаблоне, я бы использовал асинхронный канал и его преимущества для экономии кода и автоматической отмены подписки. Однако согласно этому ответу следует избегать множественных ссылок на одну и ту же асинхронную переменную в шаблоне, например:

// It works, but don't do this...

<ul *ngIf="value$ | async">
    <li *ngFor="let val of value$ | async">{{val}}</li>
</ul>

В этой ситуации я бы вместо этого создал отдельную подписку и использовал ее для обновления неасинхронной переменной в моем компоненте:

// Component

valueSub: Subscription;
value: number[];

ngOnInit() {
    this.valueSub = this.store$.pipe(select(selectValue)).subscribe(response => this.value = response);
}

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

// Template

<ul *ngIf="value">
    <li *ngFor="let val of value">{{val}}</li>
</ul>

Технически, можно достичь того же результата без valueSub, но требования приложения означают, что это правильный выбор.

Принимая во внимание роль и продолжительность жизни наблюдаемого, прежде чем решить, стоит ли подписываться

Если две или более наблюдаемых используются только вместе, соответствующие операторы RxJS должны использоваться для объединения их в одну подписку.

Точно так же, если first () используется для фильтрации всего, кроме первой эмиссии наблюдаемой, я думаю, что есть более веская причина экономить ваш код и избегать «лишних» подписок, чем для наблюдаемой, которая играет постоянную роль в сессия.

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

Относительно отписок:

Точка против дополнительных подписок является то , что все больше отменяет подписки требуется. Как вы сказали, мы хотели бы предположить, что все необходимые отписки применяются на Дестрой, но реальная жизнь не всегда идет так гладко! Опять же, RxJS предоставляет полезные инструменты (например, first () ) для упрощения этого процесса, что упрощает код и уменьшает вероятность утечек памяти. Эта статья содержит соответствующую дополнительную информацию и примеры, которые могут иметь значение.

Личные предпочтения / многословие против краткости:

Примите во внимание ваши собственные предпочтения. Я не хочу отклоняться от общей дискуссии о многословности кода, но цель должна состоять в том, чтобы найти правильный баланс между слишком большим «шумом» и чрезмерной загадочностью вашего кода. Это может стоить посмотреть .

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

 const obs1$ = src1$.pipe(tap(effect1))
 const obs2$ = src2$pipe(tap(effect2))
 merge(obs1$, obs2$).subscribe()

Исключительное выполнение побочных эффектов при нажатии и активация с помощью слияния означает, что у вас только одна подписка.

Одна из причин не делать этого состоит в том, что вы кастрируете большую часть того, что делает RxJS полезным. Который является способностью составлять наблюдаемые потоки и подписываться / отписываться от потоков по мере необходимости.

Я бы сказал, что ваши наблюдаемые должны быть логически составлены, а не загрязнены или запутаны во имя сокращения подписок. Должен ли эффект foo логически сочетаться с эффектом бара? Нужно ли одно другому? Могу ли я когда-нибудь не захотеть запускать foo, когда http $ выбрасывает? Я создаю ненужную связь между несвязанными функциями? Это все причины, чтобы не помещать их в один поток.

Это все даже не учитывая обработку ошибок, которой проще управлять с помощью нескольких подписок IMO