Redux Vs BehaviourSubject - 有什么區別？

Question

假設您是Angular開發人員，您可能擁有一項名為User Service的服務。 此服務具有您的組件訂閱的行為主題（請參閱rxjs），並且假設該服務還具有一些方法來更改用戶狀態。

您的頂級組件偵聽用戶服務狀態並將其輸入到其子組件。 然后，該子組件調用服務上的方法來更改用戶狀態，並且行為主體發出新值。 現在，您的組件偵聽獲取更新的值並將其傳遞給其子級。

或者在另一個實現中，您在同一級別擁有一堆組件來監聽狀態更改。 一個調用服務方法來改變狀態並發出狀態，所有組件監聽都獲得新狀態。

在Redux方面，我很新，但我知道有一個州區。 你的組件改為寫入狀態並從那里聽取狀態。

我沒看到差異？ 我知道Redux還允許您查看實際調用哪些操作來更改狀態，而在行為主題示例中，它們完全解耦，並且沒有關於狀態更改的原因或方式的概念 - 他們只知道狀態現在是什么。

有人可以解決一些問題嗎？

Answer 1

當我遇到一個非常常見的用例時，我遇到了這個問題：開發一個可以從我的app中的任何地方切換的加載器/微調器。

我自己提出了一個類似的問題：redux的好處究竟是什么，特別是當行為主體處理我當前的需求時。

我推薦這篇文章： https ： //blog.angular-university.io/angular-2-redux-ngrx-rxjs/

文章提到了應該使用商店的關鍵時刻，以及一些好處：

• 將組件樹注入到自然超出范圍的組件中時。 （使用actsubject避免像這樣注入）
• 性能，可測試性，工具，可預測性

它還提到使用像Redux這樣的商店的負面消息：

• 該商店確實解決了組件交互的問題，但它也創建了在應用程序中管理狀態的需求，否則在使用其他解決方案時可能不存在。

觀看完所有視頻，閱讀所有文字后，我認為Redux很棒。 我真的想用它。 但是，對於我目前僅共享單個對象狀態的用例：

{ show: true }

要么

{ show: false }

當rxjs / behaviorsubject以非常小的開銷完全滿足我的需要時，采用整個庫來處理這種單一狀態顯然不是正確的選擇。

這篇文章真的讓我印象深刻：

如果您不知道是否需要Redux，則不需要Redux。

我想也就是說，Redux在這里解決了一個巨大的問題：跨大型數據存儲的數據不變性。 如果你沒有那個問題......你還不需要Redux。 :)

Answer 2

Redux是Flux模式的一種實現。 這意味着行動和減少者是模式的一部分，並且具有提供不可變狀態的單一事實來源。 使用提供一段不可變狀態的服務只是redux（或使用像ngRx這樣的Flux模式的其他庫）提供的一部分。

需要注意的是，ngRx（類似於針對angular的observable所做的relx的lib）使用BehaviorSubjects作為狀態（或以ngRx術語存儲）。 所以使用BehaviorSubject絕對是它的一部分！

使用Subjects時要注意的一點是嘗試將它們設為私有，並允許組件通過返回Observable上的asObservable函數的方法來訂閱它們。 它可以讓你免於一些頭痛:)

Answer 3

我已將BehaviorSubject與redux結合使用，您可以將其用作常規observable，當您設置新值時，庫會將值克隆為新值並調度自動操作，因此您可以使用redux-devtools-extension調試它。 https://www.npmjs.com/package/redux-behavior-subject

Answer 4

我有一個Angular應用程序 ，其行為主題在全局服務中實現，用於保存和更新狀態 ，我觀察整個應用程序中的更改。

代碼非常清晰，完美無缺，完成目標並且易於排除故障。 👍

話雖如此，我花時間嘗試使用ngrx遷移到redux / flux模式 ， 雖然我得到了為狀態提供中央和不可變存儲的概念和好處 ，但感覺我在整個過程中創造了巨大的復雜性我的應用程序是為了正確實現它，並放棄了庫。

需要將副作用與ngrx效果集成在一起，這真的讓人感到沮喪。 代碼感覺不可靠，我開始遇到問題，而多個可觀察的訂閱在運行時開始出現，更不用說，與觀察我的代碼的變化，易讀性和組織有關的各種其他問題。

在一天結束時， 最好不是好的敵人？

Answer 5

我已經意識到意圖是不同的。 使用行為主題很好 - 目的是存儲一些狀態，並且您可能具有相同的狀態或一些交叉狀態，存儲在應用程序中的許多行為主體中（您不應該但它可能有效）。

redux的意圖是不同的。 它提供了一種具有單一事實來源的方法，因為狀態在整個應用程序中僅存儲和變異一個位置。 數據也是不可變的。 由於這兩個因素，有可能建立一個關於數據突變的強大的一致時間表，以及系統哪個區域引起這些突變的事件，這使得聰明的人能夠通過'倒帶來編寫聰明的工具來調試應用程序時間'。

這里的其他答案很棒，但我覺得它們處理的是實現細節，比如動作（明顯的）和縮減器（變異函數），真正的要點是差異很小，因為它存在於通量模式和觀察者模式。

通量模式如上所述 - 數據存儲，您可以以不可變的單一真實方式觀察。 我相信你可以說它是一個使用狀態模式和觀察者模式的復合模式。

觀察者模式是通過監聽事件（可能是相同的事件）來解耦代碼，並運行具有不同單一職責的不同代碼區域以確保解耦。 例如，用戶通過彈出窗口在論壇上更改其用戶名，他們在打開頁面上發布的所有帖子都應該使用新名稱進行更新，並且網站標題右上角顯示的用戶名應該更改。 這些是不同的責任范圍。