# 動機 隨著 JavaScript 單頁應用開發日趨復雜，**JavaScript 需要管理比任何時候都多的 state （狀態）**。 這些 state 可能包括服務器響應、緩存數據、本地生成尚未持久化到服務器的數據，也包括 UI 狀態，如激活的路由，被選中的標簽，是否顯示加載中動效或者分頁器等等。 管理不斷變化的 state 非常難。如果一個 model 的變化會引起另一個 model 變化，那么當 view 變化時，就可能引起對應 model 以及另一個 model 的變化，依次地，可能會引起另一個 view 的變化。直至你搞不清楚到底發生了什么。**state 在什么時候，為什么，如何變化已然不受控制。** 當系統變得錯綜復雜的時候，想重現問題或者添加新功能就會變得舉步維艱。 如果這還不夠糟糕，考慮一些**來自前端開發領域的新需求**，如更新調優、服務端渲染、路由跳轉前請求數據等等。我們前端開發者正在經受前所未有的復雜性，[我們是時候該放棄了嗎？](http://www.quirksmode.org/blog/archives/2015/07/stop_pushing_th.html) 這里的復雜性很大程度上來自于：**我們總是將兩個難以厘清的概念混在一起：變化和異步**。 我稱它們為[曼妥思糖與可樂](https://en.wikipedia.org/wiki/Diet_Coke_and_Mentos_eruption)。如果把二者都分開，能做的很好，但混到一起，就變得一團糟。一些庫如 [React](http://facebook.github.io/react) 試圖在視圖層禁止異步和直接操作 DOM 來解決這個問題。美中不足的是，React 依舊把處理 state 中數據的問題留給了你自己。 跟隨 [Flux](http://facebook.github.io/flux)、[CQRS](http://martinfowler.com/bliki/CQRS.html) 和 [Event Sourcing](http://martinfowler.com/eaaDev/EventSourcing.html) 的腳步，通過限制更新發生的時間和方式，**Redux 試圖讓 state 的變化變得可預測**，而這些限制條件反映在 Redux 的 [三大原則](#)中。