## 演職表 在我解釋這些角色間如何交互前，先逐個介紹下它們。 ### Action Creator 第一個角色是 Action Creator。它負責創建 Action，作為全部改變和交互的入口。當需要改變應用的狀態或有 View 需要更新時，你需要觸發一個 Action。  我認為 Action Creator 就像電報員。你拿著你想要寄出的消息，找到 Action Creator，它就把消息格式化成系統其他部分可以理解的形式。 Action Creator 把 type 和 payload（載荷）封裝成一個 Action。type 是你預定義的多個 type （通常是一個常量列表）之一，代表系統特定的 action。舉個例子的話就像 MESSAGE_CREATE 和 MESSAGE_READ 這樣的。 系統的某個部分知道所有可能的 action，這或許存在副作用。一個新來的工程師，打開 Action Creator 文件，看到全部的 API——所有可能改變的狀態——它們都是你的系統提供的。 一旦 action 消息創建好了，Action Creator 就會把它傳遞給 Dispatcher。 ### Dispatcher Dispatcher 就是一個巨大的回調函數登記表。就好比一個坐在電話總機前的接線員。它保存著所有需要發送 action 的 store 列表。當 Action Creator 給過來一個 action，它會把這個 action 傳遞給各個 store。  Dispatcher 的行為是同步的，這對我之前講的多個乒乓球游戲有所幫助。如果想要在 store 之間實現依賴，有的更新完了其他的才能更新，你可以使用 Dispatcher 提供的 waitFor() 來實現。 Flux 的 Dispatcher 不同于其他大部分架構中的 dispatcher。它會把 action 傳遞給所有登記在冊的 store，而不在 action 的類型。也就是說 store 并不是訂閱某些 action，而是聆聽每一個 action，從中過濾它關心的。 ### Store 輪到說 store 了。store 保存了整個程序的狀態，而且狀態變化的邏輯都在 store 里。  我覺得 store 就是一個充滿控制欲的長官。所有的狀態變化都必須由它來親自操作的。而且你不能直接通過 store 來更改狀態。在 store 上并沒有 setter API。要更新一次狀態，你必須經過正當的手續——必須通過 Action Creator/Dispatcher 通道。 上面說了，如果 store 在 dispatcher 中注冊了，那所有的 action 都會發給它。在 store 中，通常會使用一個 switch 語句來判斷 action 的類型，決定是否對這個 action 做出相應。如果 store 關心這個 action，就會根據 action 找出需要變化的部分，更新 state。 只要 store 對 state 做出了變更，就會觸發 change 事件，通知視圖控制器狀態已經變化了。 ### Controller View 和 View View 層負責將 state 渲染給用戶，并接受用戶的輸入。  View 就像一個主持。它對應用一無所知，只懂該如何把交到它們手中的數據渲染格式化成用戶能夠理解的輸出（HTML）。 Controller View 是一個中間管理者。store 在 state 變化時通知它，它收集新的狀態，并將更新后的狀態傳遞給所有大管轄的 View。