動機(jī)

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

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

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

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

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