使用主題值時可觀察與訂購

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">將創建大多數IDE中未知類型的視圖變量數據 。
• 陡峭的學習曲線。 RXJS不容易掌握。
• 用debugger;很難debugger; 因為該組件沒有要調試的狀態。
• 很難進行單元測試。 沒有組件狀態可以斷言它是正確的。

有狀態的組件

當組件具有視圖模板中使用的屬性時，該組件為有狀態的 。 必須更改組件的內部狀態才能表示視圖中的更改，這是Angular中組件的默認類型。

該方法具有以下優點。

• 開發，維護和閱讀源代碼更加容易。
• @Input()綁定首先是有狀態的 。
• IDE具有更好的組件屬性自動完成功能。
• 學習曲線更輕松。 無需學習第三方庫。
• 使用debugger;更容易debugger; 在瀏覽器中，因為您可以看到組件的當前狀態 。
• 單元測試更容易。

該方法具有以下缺點。

• 使用服務中的外部狀態時，最有可能出現“檢查后表達式已更改”錯誤。
• 當您混入可觀察對象時，源代碼會因subscribe()調用而變得混亂。
• 您必須手動將反應流轉換為組件狀態，並編寫類似data.subscribe(value => this.data = value) 。
• 使用外部觀測值時，變化檢測成為一個挑戰。
• 它需要更多的代碼行來創建可響應外部事件和可觀察對象的響應組件。

結論

在決定使用兩種方法中的哪一種時。 我建議從有狀態的組件開始，但是將您的技能提高到反應性的組件。

根據我的經驗，反應性組件是必經之路，因為它們是可觀察流的目標 。 這些組件將可觀察到的東西聚集在一起，以創建該數據的響應視圖，並且它們對這些流中的更改自動做出反應。 同時，將數據合並為目的地更多是Angular中的體系結構設計。 因此，這是一個更廣泛的討論和主題，但請繼續學習，您將會到達那里。