動機

隨著 JavaScript 單頁應用開發(fā)日趨復雜，JavaScript 需要管理比任何時候都多的 state （狀態(tài)）。 這些 state 可能包括服務器響應、緩存數(shù)據(jù)、本地生成尚未持久化到服務器的數(shù)據(jù)，也包括 UI 狀態(tài)，如激活的路由，被選中的標簽，是否顯示加載中動效或者分頁器等等。

管理不斷變化的 state 非常難。如果一個 model 的變化會引起另一個 model 變化，那么當 view 變化時，就可能引起對應 model 以及另一個 model 的變化，依次地，可能會引起另一個 view 的變化。直至你搞不清楚到底發(fā)生了什么。state 在什么時候，為什么，如何變化已然不受控制。 當系統(tǒng)變得錯綜復雜的時候，想重現(xiàn)問題或者添加新功能就會變得舉步維艱。

如果這還不夠糟糕，考慮一些來自前端開發(fā)領域的新需求，如更新調(diào)優(yōu)、服務端渲染、路由跳轉(zhuǎn)前請求數(shù)據(jù)等等。我們前端開發(fā)者正在經(jīng)受前所未有的復雜性，我們是時候該放棄了嗎？

這里的復雜性很大程度上來自于：我們總是將兩個難以厘清的概念混在一起：變化和異步。 我稱它們?yōu)?a rel="external nofollow" target="_blank" target="_blank">曼妥思糖與可樂。如果把二者都分開，能做的很好，但混到一起，就變得一團糟。一些庫如 React 試圖在視圖層禁止異步和直接操作 DOM 來解決這個問題。美中不足的是，React 依舊把處理 state 中數(shù)據(jù)的問題留給了你自己。

跟隨 Flux、CQRS 和 Event Sourcing 的腳步，通過限制更新發(fā)生的時間和方式，Redux 試圖讓 state 的變化變得可預測，而這些限制條件反映在 Redux 的 三大原則中。