React.js - flux vs全局事件總線

Question

在全球事件總線上使用Flux有什么優勢？ 我認為調度員就是所需要的：

1. 組件將數據發布到調度程序的“用戶事件”
2. 調度程序執行訂閱商店的處理程序
3. handler使用商店的更新屬性發布'update event'
4. dispatcher執行訂閱組件的處理程序，並使用商店的更新屬性更新組件狀態

我在這里錯過了什么，我不能沒有Flux？

Answer 1

我認為其他人對應用程序結構和change事件的看法很重要，但我應該補充一點：

調度程序的waitFor方法是使用調度程序注冊商店與偵聽全局事件總線的商店之間的最大區別。 此方法允許您管理哪些商店在其他商店之前更新。 當您希望StoreB在決定做什么之前先了解StoreA所做的事情時，這一點至關重要。

您可以將調度程序視為具有waitFor方法的全局事件總線，這有點准確。

Answer 2

我不是一個流動的專家，但是一個架構不能讓你做一些以前不可能的事情，它給你的應用程序一個可擴展和可理解的結構。

Answer 3

我相信這一切都與代碼結構有關，即使是大規模也是可以理解的。

假設您擁有appState ，其中包含組件的基礎數據。

組件調用操作 。 Action負責從XHR收集數據或修改組件中的傳入數據，然后將完整數據發送到訂閱的商店。

Store是代碼中唯一可以修改appState ，它基本上是唯一的，它的作用。 它從操作中獲取數據並將其存儲到appState或根據操作從appState刪除一些數據。

然后你觸發stateChanged事件，你的組件應該監聽並重新渲染。

所以你在行動中擁有所有特定於行動的邏輯。 您只在商店中處理appState 。 這應該可以幫助您保持代碼可以理解。

通量模式

我理解為什么只發送完整數據的好主意主要來自本文 。 它基於官方Facebook Flux圖

這種方法的優點是：

• 存儲是簡單和同步的，不包含決策邏輯，只處理給定的數據
• 沒有必要在商店中觸發另一個動作，這將打破Flux的單向鏈
• dispatcher是所有狀態更改的單一通道，它知道處理什么數據的操作，因此更容易進行調試

Answer 4

你基本上描述了助焊劑，唯一的區別是：

4. 商店發出變更事件

並且更新其狀態的組件不是助焊劑的一部分，這是整合助焊劑和反應的常見做法。

Flux只列出了這些部分，並給出了每件作品的指導原則。

它本質上是一個主要事件發射器（調度程序），事件類型（動作），在調度程序上發出事件的函數（動作創建者;事件體是有效負載），以及其他事件發射器：保持狀態，聽取調度程序並發出變更事件（商店）。

至少這是它在JS中的工作方式。 核心原則是單向數據流。 有許多事件發射器用於雙向通信。