最近公司需要重構一個后臺管理系統(tǒng)，原因就是用到的技術比較過時，例如：react的版本是0.14.7，antd的版本還是0.12.4。
之前嘗試重構了一個頁面，這個頁面的數(shù)據(jù)非常復雜，老的代碼解決的方案往往是context，對于這種方式，官網(wǎng)給出了一個Notice：
我理解的這段話的意思應該是首先不要濫用，這樣會產(chǎn)生很多magic number從而讓代碼閱讀都不知所云，使用context的場景往往應該是有一個父組件管理很多數(shù)據(jù)來讓它的子組件們共享這些數(shù)據(jù)。
這種方式很容易讓人聯(lián)想到了redux，為了管理這些復雜的數(shù)據(jù)，我在下一個頁面中使用了React+Redux-Saga+Seamless-Immutable+Reduxsauce這樣的一種架構方式。
為什么要這么做
Redux
You Might Not Need Redux，當你不知道你是否需要Redux的時候，那你就是不需要它。我們在使用redux實現(xiàn)一個功能的時候，往往需要修改三個文件：1、View層dispatch一個action；2、Controller層收到這個action并執(zhí)行一些邏輯，dispatch一個action給Modal層；3、Modal層處理數(shù)據(jù)。
而在我新開發(fā)的這個頁面中，涉及到了一些非常復雜的情況：多種用戶（供應商、子商戶）、多種模式（正常報名、修改報名），以及要修改一些粒度非常小的數(shù)據(jù)（為一個商戶關聯(lián)商品并將商品信息展示出來，修改關聯(lián)的商品的圖片等）。拿到這種需求的時候，我第一時間就想到了必須使用這個工具，否則數(shù)據(jù)的龐大和復雜會讓我陷入惡夢之中。
saga
起初我只是想學習調研一種新的使用redux的方式?？墒请S著學習的深入和使用得越來越多，我對它越發(fā)著迷。saga其實是redux的一個中間件，它提供了非常優(yōu)秀的異步處理方式，就是使用Generator函數(shù)來讓Promise調用扁平化，像編寫同步代碼一樣編寫異步代碼。其次，saga還提供了很多優(yōu)秀的方法來控制流程，如：fork執(zhí)行一個非阻塞操作；Race 同步執(zhí)行多個 effect，然后一旦有一個完成，取消其他 effect；takeLatest 意味著我們將執(zhí)行所有操作，然后返回最后一個(the latest one)調用的結果。如果我們觸發(fā)了多個時間，它只關注最后一個(the latest one)返回的結果等。不僅如此，我從中還摸索到的一種“鎖”的概念（后面會講到，這種方法對于 redux化的Stateless Component非常有用，可以用來模擬生命周期函數(shù)而無需使用高階函數(shù)）。
Seamless-Immutable
Shared mutable state is the root of all evil（共享的可變狀態(tài)是萬惡之源）
-- Pete Hunt
我們都知道react的state是不可變的，修改state的時候(特別是引用類型)不能直接使用this.state.foo.bar = newValue，因為React的diff算法是shallow eqaul的。我們可以通過cloneDeep來深拷貝原state，再修改這個拷貝出來的新值，再setState。
或者使用Seamless-Immutable來解決這個問題。一個immutable值一旦生成就不可改變，只要對這個值進行有副作用的操作都會生成一個新的值。同時Immutable值會采用結構共享，即如果對象樹中一個節(jié)點發(fā)生變化，只修改這個節(jié)點和受它影響的父節(jié)點，其它節(jié)點則進行共享。這樣也避免了cloneDeep帶來的性能消耗。如果每次都生成一個新的對象，那么就可以把這些對象存儲下來，實現(xiàn)時間旅行就非常簡單了。
Reduxsauce
這個工具主要是用來簡化reducer的寫法，避免判斷action.type而產(chǎn)生的無數(shù)switch...case...，以及可以非常輕松地生產(chǎn)出不重復的action.type等功能。
if you trade something off, make sure you get something in return.（如果你付出了一些東西，一定要確保你能獲得一些東西），以上介紹了技術選型的原因，一定不要為了使用技術而使用技術，帶著明確的目標，下面介紹一下這套系統(tǒng)的搭建方法。
