Redux 專門用于管理狀態
Redux 官方文檔對 Redux 的定義如下：
一個面向 JavaScript 應用的可預測狀態容器。
你可能會問，“如果 React 已經在為我的應用管理前端狀態，為何還需要 Redux？”
使用 Redux 的主要優勢之一是它可以幫你處理應用的共享狀態。如果兩個組件需要訪問同一狀態，該怎么辦？這種兩個組件同時需要訪問同一狀態的現象稱為“共享狀態”。你可以將該狀態提升到附近的父組件，但是如果該父組件在組件樹中向上好幾個組件的位置，那么將狀態當做屬性向下一個一個地傳遞，這項工作很快就會變得乏味。此外，在該父組件和該子組件之間的組件甚至根本不需要訪問該狀態！
在構建 web 應用時，Redux 不僅使我們能夠以有條理的方式 存儲 數據，而且使我們能夠在應用的任何位置快速 獲取 該數據。只需告訴 Redux 到底哪個組件需要哪個數據，它就會為你處理后續一切工作！
借助 Redux，你可以控制狀態改變的時間、原因和方式。
Store：單一數據源
Redux 的基本原則之一是存在單一數據源：Store。也就是說，Store 包括應用的全局狀態，全存儲在一個對象樹中。
只有單個狀態樹，對于應用的很多方面都有好處。假設在構建應用時嘗試實現撤消/重做功能。如果所有狀態都存儲在一個樹（單一數據源）中，則實現起來比數據分散在多個組件中簡單多了。狀態集中到一個位置后，調試和檢測過程也會簡單很多！
為了保持這種單一數據源特性，Redux 制定了幾條規則，確保一切盡在掌控。規則一：Redux 應用中的狀態是只讀的，即 Redux 狀態 不可變。例如，React 組件不能直接寫入 Redux 狀態，而是發出 intent 來更新狀態。
實際上，只有叫做reducer的純函數能夠更改狀態。暫時別擔心這些概念，我們會在下節課深入講解的！
隨著單頁面應用變得越來越復雜，正確地管理狀態這一需求更加重要。例如，除了管理表格狀態（例如《React 基礎知識》課程中的 Contacts 應用）等數據外，應用可能還需要管理：
- 服務器響應
- 緩存的數據（例如用戶）
- 尚未保存到服務器上的本地數據
除此之外，UI 狀態也越來越復雜。同一應用可能還需要跟蹤：
- 當前路由
- 當前選擇的標簽頁
- 頁碼控件
Redux 便因此而生，它專門用于管理上述所有這些內容。創建者 Dan Abramov 在 2015 年根據 Flux 架構創建了 Redux，并從 Elm 編程語言中汲取了經驗。從那以后，Redux 變得越來越受歡迎，每月的下載量達到數百萬。
總結
Redux 是一個 JavaScript 庫，用于管理應用的前端狀態。Redux 并非 React 應用的必須條件，但是隨著網絡應用的復雜性越來越高，狀態管理不當可能會導致 bug。Redux 應用中的全局狀態存儲在單一數據源 store 中。因為狀態的更新受到嚴格控制，使得 Redux 非常具有可預測性。實際上，開發人員喜歡 Redux 的主要原因之一就是它的可預測性。我們來看看背后的原因！
更多資料
- Redux 文檔中的 動機 / 英 部分
- Redux 的三大原則 / 英
- GitHub 上的 Redux
- npm 上的 Redux
