目錄
- 為什麼要進行資料管理？
- 怎麼有效地進行資料管理？
- 資料管理工具
- 1. Flux
- 2. Redux
- 3. Vuex
- 使用資料管理工具的場景
- 相關資料
主要講解一下前端為什麼需要進行資料管理，有效的資料管理應該是什麼樣子的，最後挑選Flux、Redux、Vuex進行對比講解。
元件式開發的核心思路是MVC，Model層的資料發生變化，驅動View層的視圖發生變化。試想一個場景，如果ModelA觸發ModelB變化，導緻ViewB發生變化，ViewB發生變化時，觸發了ModelC變化，ModelC又觸發了其他Model的變化...，我們想知道一個View的變化究竟是那個資料導緻的，追查起來就很困難，于是就記錄資料的變化就很有必要了，其實換一個高大上的名字就是資料狀态管理。
1. 資料集中管理
view中的資料統一放置到一個倉庫（store）中，要渲染頁面的時候，從中取出目前狀态的資料（state），然後将state中的最新的資料通過props傳遞到元件中，然後渲染元件，實作試圖展現。
2. 精細化拆解資料操作
要修改store中的state，為了做到資料的操作可追溯，盡量将資料的操作拆解成一個個小函數，當然純函數最好。
3. 單向資料驅動
元件中不能直接修改state的值，修改state，隻能發出修改請求（action），由action觸發資料操作。
總之，資料集中管理就需要應用使用唯一的資料Tree，存放在store中；精細化拆解資料操作就是需要提供小而純的函數，來修改state；單就向資料驅動需要提供唯一能修改state的管道。
Flux資料流的順序是:
View發起Action->Action傳遞到Dispatcher->Dispatcher将通知Store->Store的狀态改變通知View進行改變
ps:基于Flux架構思想寫的一個小demo
Redux相對于Flux的改進：
- 把store和Dispatcher合并,結構更加簡單清晰
- 新增state角色，代表每個時間點store對應的值，對狀态的管理更加明确
Redux資料流的順序是:
View調用store.dispatch發起Action->store接受Action(action傳入reducer函數,reducer函數傳回一個新的state)->通知store.subscribe訂閱的重新渲染函數
ps:阮一峰老師的Redux+React小demo
- 改進了Redux中的Action和Reducer函數，以mutations變化函數取代Reducer，
- 無需switch,隻需在對應的mutation函數裡改變state值即可
- 由于Vue自動重新渲染的特性，無需訂閱重新渲染函數，隻要生成新的State即可