如何通俗易懂地解釋 Redux 和 Flux 的區別和實現意義？
01-29
redux 實現了 state 和 reducer 的分離，而不是共同的雜糅於 store 中，redux 只有一個 state（store.getState()），並且 state 是只讀，每次修改生成新的版本
於是就可以實現 time travel 的開發體驗，可以旅行到任意版本的數據，並且由於有 hot reload 這種機制，後端修改 reducer 實現，瀏覽器可以準確替換而不影響 store 對象和數據，開發不用重複操作 use case，效率上有了不小的提升，另外一方面是便於 server render，更進一步實現同構。Redux是一個友好簡潔的flux模式的實現意義：實現前後端同構，更好組織UI組件事件分發然而，對我來說用Redux只是看上React的函數式編程，實際業務實踐更偏愛Vue.js
圖源：GitHub - kenberkeley/redux-simple-tutorial: Redux 莞式教程。本教程深入淺出，配套入門、進階源碼解讀以及文檔注釋豐滿的 Demo 等一條龍服務
Redux：受Flux啟發的一種架構風格如何理解 Facebook 的 flux 應用架構？ - 前端開發
React是數據驅動式的UI component體系，是一個開放的數據依賴式，非自閉OO對象。它會有以下挑戰
- render方法可能很大，component顯示邏輯是一次性在render里實現的。這裡往往有兩部分邏輯實現，初次數據綁定，與用戶交互之後的演算法。
- render出一個ReactElement樹，但這個樹中的一些組件、UI元素因為計算被前移了，這會導致這個樹看起來不太完整，進而不太直觀。
- 雖然可以分解成小的component，構建大的Component可能是個挑戰，因為所有邏輯都依賴於外部數據，而外部數據相對不穩定，組件失去了自我邊界的保護，非自閉。
- 當交互複雜，組件的state也會越來越大，render全局演算法會越來越難寫。
- 把子組件的行為傳上來也是一件不顯化的事，往往需要把父組件的一個函數作為回調傳給子組件。
- 大組件往往有多個Page，這幾個Page如何交換數據是個很大的挑戰
推薦閱讀：