[Redux #1] 認識 React 的好朋友
Redux 是一個狀態管理套件，有著自己一套狀態管理概念與架構，可以讓開發者更容易了解狀態在何時、何地、為什麼以及如何被更新，讓狀態變成「可預測」的，最常與 React 搭配著使用，解決了 React 需要透過 prpo drilling 的方式將狀態傳來傳去，無法管理狀態的問題，但 Redux 其實也可以套用在任一框架、任一程式語言。
Redux 的使用情境
- 為中型或大型的 APP ，多人開發。
- APP 中有需要管理的大量共用資料。
- 更新資料狀態的邏輯可能很複雜或需要頻繁的更新。
狀態管理是什麼
可以想像成 View 跟 資料間的對應關係與互動，因此對前端來說狀態管理就非常重要。
不同的框架下狀態管理機制也不同：
- VanillaJS、JQuery：思考的重點會偏向從於畫面，通常拿取資料會思考從畫面上拿取，資料跟畫面是分開的。
- Vue、Angular：資料與畫面雙向綁定，將屬性綁定與事件綁定結合再一起，不管改資料或改畫面兩邊都會更新。
- React：只能透過資料狀態的改變來更新畫面，因此只需要管理資料。
Redux 的由來
Redux 是從 Facebook Flux 衍生出來的一個套件，「Flux」是 Facebook 提出 React 後晚一年提出的一個架構，在 MVC 的架構裡面 Model 跟 View 會存在著複雜的關係，可能一個動作，會更動到好幾個 Model 或好幾個 View，當應用程式越來越大後，就很難追蹤因此狀態管理就變得極為重要。
我們接著深入研究 Flux 的架構
- View：畫面
- Store：管理資料狀態（state）的地方
- Action：動作
- Dispatcher：分發器
當使用者在 View 中執行了一個動作想要改變資料，必須發送一個 Action 透過 Diapatcher 更動 Store 裡面的資料後傳送回 View 中。
這樣有個好處是，改變資料這件事情都必須透過 Dispatcher 進行，形成一個單向資料流，更容易追縱、管理資料狀態。
在小型的 APP 中，這種架構可能會被認為程式被複雜根本多此一舉。但在像 Facebook 這種大型 APP，透過這種狀態管理架構，可解決一些問題。
而 Redux 繼承了 Flux 的概念，將其架構與 Function 結合。
Redux 架構
當使用者點擊按鈕產生了事件，事件會產生 Event Handler ，Dispatch 一個 Action（指令，JS 的物件）傳送到 Store （儲存資料的地方），經過 Reducer（跟 Array.prototype.reduce() 很像）拿新進來的 Action 跟原本的 State 結合之後回傳新的 State 再更新到 UI 中。
透過資料的流動，可以了解 Redux 是一個單向的數據流，這邊在特別提及 Redux 一些特性
- APP 只會有一個 Store，Store 儲存了整個 APP 所有的 State。
- 在每次 Action 觸發請求後，Redux 都會產生一個新的 object 更新 State，而不修改當前的 State。
下一篇我們實際將 Redux 結合至 React 當中～
重點筆記
- Redux 是一個狀態管理機制的套件。
- Redux 使用「單向數據流」的 APP 結構。
- 改變東西只能透過 Dispatch 發送 Action。
- Store 保存 APP 中資料狀態的地方。
- State 在 Redux 中指被 Store 所管理的單一狀態值。
- Action 是一個改變 State 的指令，大部分是一個 JS 物件。
- Dispatch 類似一個分發器，用來接收 Action。
- Reducer 會將 Action 傳遞的值與 Store 中原有的 State 進行處理，回傳一個「新的 State」。
