Наблюдаемый против подписки при использовании значений субъекта

Question

Я довольно новичок в Angular и, насколько я могу судить, Subject - это стандартный класс, используемый для многоадресной рассылки. Испытывая этот класс, я обнаружил, что есть два (возможно, даже больше) способа справиться с изменениями в его стоимости.

1. Использование Observable объектов типа внутри компонента напрямую

   В этом подходе Observable объявляется внутри компонента следующим образом:

   foo$ : Observable<boolean>;
   

   и затем используется в html-файле с использованием следующего метода:

   <p *ngIf="(foo$ | async) as foo">Bar!</p>
   

2. Второй подход заключается в том, чтобы в компоненте был объект типа Subscription, который назначается некоторой переменной-члену:

   s: Subscription;
   foo: boolean;
   

   Если подписка инициализируется следующим образом:

   constructor(private fbs: FooBarService) {
       this.s = fbs.fooObservable.subscribe(v => this.foo = v);
       //  this.s.unsubscribe() is called within ngOnDestroy()
   }
   

   HTML-код будет использовать такой код:

   <p *ngIf="foo">Bar!</p>
   

Есть ли какая-либо причина, кроме личных предпочтений, предпочесть любой из этих подходов?

Answer 1

Есть ли какая-либо причина, кроме личных предпочтений, предпочесть какой-либо из этих подходов?

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

Один подход называется реактивным компонентом , а другой - компонентом с состоянием .

Реактивные компоненты

Представление обрабатывает представление данных из наблюдаемых с использованием канала async.Если компонент использует только наблюдаемые и async канал для представления, тогда компонент не имеет состояния и реагирует на изменения автоматически через представление.Это помогает создать ощущение более сухое для шаблонов.

У этого подхода есть следующие преимущества.

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

Этот подход имеет следующие недостатки.

• Разработчики, скорее всего,писать data.subscribe(value => this.value = value), когда они не понимают реактивного программирования.
• Исходный код может быть трудным для понимания, когда несколько наблюдаемых объединены, переключены или объединены без особого объяснения причин.
• Представляетриск утечек памяти и потерянных подписок.
• Разработчики могут иногда использовать операторов, когда они не понимают всепобочные эффекты.Используя mergeMap() вместо switchMap() в качестве примера.
• Вы должны отслеживать жизненный цикл наблюдаемых.
• Редакторам IDE труднее автозаполнение типов ,Например;<ng-container *ngIf="data$ | async as data"> создаст переменную представления data неизвестного типа в большинстве IDE.
• Крутая кривая обучения.RXJS нелегко освоить.
• Трудно отладить с помощью debugger;, потому что компонент не имеет состояния для отладки.
• Сложнее выполнить модульное тестирование.Нет состояния компонента, которое могло бы утверждать, что оно является правильным.

Компоненты с состоянием

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

Этот подход имеет следующие преимущества.

• Проще разрабатывать, поддерживать и читать исходный код.
• @Input() привязки с состоянием для начала.
• IDEулучшенные функции автозаполнения для свойств компонентов.
• Имеет более легкую кривую обучения.Нет необходимости изучать стороннюю библиотеку.
• В браузере проще использовать debugger;, поскольку вы можете видеть текущее состояние компонента.
• Это проще для модульного тестирования.

Этот подход имеет следующие недостатки.

• Скорее всего, при использовании выдается ошибка «Выражение изменилось после того, как его проверили»внешние состояния из сервисов.
• Исходный код загромождается вызовами subscribe(), когда вы смешиваете в наблюдаемых.
• Вы должны вручную преобразовать реактивные потоки в состояние компонента и написать код, подобный data.subscribe(value => this.data = value).
• Обнаружение изменений становится проблемой при использовании внешних наблюдаемых.
• Требуется больше строк кода для создания отзывчивого компонента, который реагирует на внешние события и наблюдаемые.

Заключение

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

По моему опыту, реактивные компоненты - это путь, потому что они являются пунктами назначения для наблюдаемых потоков. Это компоненты, которые объединяют наблюдаемые для создания отзывчивого представления этих данных, и они автоматически реагируют на изменения в этих потоках. В то же время объединение данных в качестве адресата - это скорее архитектурный проект в Angular. Так что это более широкое обсуждение и тема, но продолжайте учиться, и вы получите там.