Redux 簡介：我終於看穿它了

Redux 把資料放在 store 中，它是個資料庫，但 Redux 不用常見的 SQL 介面，要開發者自訂指令介面。這介面有簡單的標準，他只接受 Action = {type, payload} 物件的輸入。在傳統的資料庫中，下了 SQL 資料庫就會照指令，來更新資料庫，但在 Redux 中，開發者需要自行寫一個 Reducer 來處理輸入的 Action 指令。和傳統資料庫不同的是，這個 Redux 資料庫變了之後，Redux 會 push 變動了的資料到訂閱者 (一個 Javascript 物件)，行為就像是 Baas 服務 (parse, firebase) 常見的 push message。Redux 和傳統關聯式資料庫最大的不同點是，Redux 用 JS 物件或變數來儲存資料；傳統資料庫因為有大量相關的資料，所以用資料表 (data array, data table) 來儲存。這讓 Redux 的狀態樹一直呈現很難視覺化的情況，目前樹狀結構最好的視覺化就是，Browser 的 dev tool 了。如果能把 Redux state 架構轉成 html，也許會有很好的效果也不一定。 另一個選項是 D3.js 的 Simple Tree。

簡單的資料庫列表比較

Redux 和 Firebase 的資料儲存方式很相近，可以很好的一起運用整合。也許進一步把 client 的資料再切為，Server Data 和 View Data 的設定會更好。Server Data will always synced with Firebase.

另外一提，Redux 實際上就只是個資料庫 (Model)，只有 input & outpt，哪有什麼 middleware… in the middle of what？Redux-middleware 實際上是一部分的 controller，跟 Redux 無關啊。React 也包含 Controller。畫成圖來表示

Flux 把傳統的 MVC 切成了上行和下行，形成了一個循環資料流，它最大的優點是有 paper 支持的 Single Source of Truth。想像一下 bug 在房間亂跑好抓還是... bug 繞著固定的圈圈跑，bug 繞圈圈跑的話，在原地等 bug 跑過來就抓到了。

總結一下，說穿了 Redux 就是一個啥功能都沒有的資料庫設計規範。也因此，他的文件很長、相關模組很多。

Redux = 事件驅動系統 = 伺服器

Redux 做的事情其實很簡單 ( 主程式才99行 )，就是可客制 Event 的 Event System。這概念在別的領域已經很成熟。但因為 Redux 的目標使用者是 Flux 的使用者，套用了很多原來 Flux 裡的專有名詞，所以對非 Flux 使用者變得很難懂。這邊透過類比大家都知道的名詞，目標讓 Redux 的概念連六歲小孩都能理解。

Flux：

Actions trigger reducer to update states in the store.

Redux 的行為等於事件驅動系統 ( Event-driven System ) / 有限狀態機 ( FSM )：

Events trigger event handler to update states in the machine.

Action	Event | Signal | Message
Reducer	Event Handler | Finite State Machine 中的 transducer

Redux 的行為等於一個網頁伺服器：

When a request came, using route table mapping to get a method to process it。

Action	Http Request
Store.dispatch(Action)	送 Request 到 Server
Reducer	Router 把 Request 送到對應的 Router Method，更新 Database
Store	Database
UI / React	Http Response

Redux的行為等於巷口那家... 哎 想不出來比較生活的說法。

現在有沒有覺得 Redux 很 Awesome？好像沒有啊... 但我們回到瀏覽器的環境重新看一下，因為 HTML 的元件很小，開發者會組合 HTML元件成為可重複使用的「大元件」。但問題是瀏覽器中的 「事件處理系統」 是針對 HTML 小元件的，沒有給「大元件」的。於是Redux 提供了給開發者可以自行定義事件的「大元件」事件處理系統，因為你可以控制整個事件處理系統，重播和紀錄事件都變成毫不費力的事。現在又感覺到  Redux 很 Awesome了吧!!!

故事到了這邊，一定會想這樣解說，哪個六歲小孩能了解啊，相信這是大家共同的疑惑，不過 「投資一定有風險，基金投資有賺有賠，申購前應詳閱公開說明書」，我會反省的...

---

延伸閱讀：
redux 的專有名詞解釋
Redux Issue 891：Is redux conflating actions with events?
六歲小孩也能懂的 Javascript Closure 說明

用 Redux 實踐「狀態機導向的介面開發」

BIG WORD ALERT!!!
———
研究了Redux.js之後，對State Machine有了更深的領悟。

上個月解了一百多題 LeetCode，深深覺得程式解問題很重要的一點就是，想出一個「資料的表達的方式」讓問題運算過程中的所有「狀態」能夠清楚的表達，之後只要叫電腦從 Initial State 算到 Final State，題目就解完了。這個「資料表達的方式」也許是 stack、也許是 Array 再加上兩個 Pointer、也許是 2D Array表達地圖狀態、或複雜一點的像是 八皇后(N-queens) 問題用四個 array 來表達row, column, 兩個斜線方向有沒有皇后。只要想完「怎麼用資料來清楚表達所有狀態？」這個題目就解一半了，如果是 backtracking / 窮舉的問題的話，那你就已經解完了。

不過，這個跟 Redux 有什麼關係呢？Redux做為Flux概念的實現，設計中 Store 是唯一的資料儲存中心，它把所有「元件狀態的資料」集中放在一起。讓開發者很容易用抽離 UI 的角度思考，一開始就把應用程式中「0. 怎麼用資料來清楚表達所有邏輯狀態？」這個問題給想清楚。這個問題解完了之後，剩下的只有兩件事：

 1. 收到使用者 Action 或伺服器的更新，要從哪個 state 換到 哪個 state：應用程式的運作邏輯，這部分 Redux 用 Reducer 做掉了。在 Reducer 中你要清楚定義狀態機中的 Transition 也就是 ( previousState, Action ) => newState 這件事

 2. 在每個state的時候，應用程式 / 元件要畫成什麼樣子：React 想解的問題

0 和 1 兩個步驟常常會平行設計、互相影響，這部分會定義你的產品功能面。
2 的步驟就是視覺化、資料傳達的部分。

—
總結，從State Machine的角度來開發只要做下面三件事：
1. 想好怎麼表達 state。 ( Redux Store )
2. 想好有哪些事件，事件會讓 state 間怎麼切換。 ( Redux Reducer )
3. 如何把狀態傳達給使用者。 ( React )
從此開發就有了 SOP。

PS: 「資料的表達方式」包含了「資料結構」和裡面結構中資料代表的意義。