Redux「七宗罪」

Redux「七宗罪」

React+Redux目前已經成爲了前端開發領域內較爲主流的一種架構模式。其中React負責頁面渲染，Redux負責管理全部的業務數據，以下圖所示。引入redux確實可以很好的將數據與UI解藕，讓React組件作到最大程度的複用性，但也帶來了不少問題，這些問題都必定程度上下降了業務開發效率。如下詳細探討redux最主要的7個問題，簡稱「七宗罪」。

一 過多的文件
衆所周知redux由三個部分組成：store、action、reducer。在使用redux時，當咱們開發一個頁面，咱們就須要定義全部和這個頁面邏輯相關的action。在處理業務數據時，我有由須要給每一個頁面或者時某種資源定義相應的reducer，長此以往，咱們的項目裏就有了許多action和reducer文件。過多的文件不只增長了開發成本還會致使開發者在進行業務開發時不斷的切換文件，下降了開發效率。

二 業務邏輯割裂
redux框架中使用了reducer這一函數式編程的工具來進行數據管理，對獲取到的數據（用戶經過UI交互產生或後臺數據返回）進行加工和保存。在前端開發中的業務邏輯通常包含了四個部分：收集數據、發送請求、接收請求、處理數據，以下圖所示，這四個步驟通常出如今一個文件裏，相對容易修改和維護。而redux把處理數據的邏輯單獨抽離出來放入了reducer中，必定程度上增長了業務邏輯開發流程，讓開發者必須定義好reducer中接受數據的格式，而且須要常常在不一樣文件中切換，形成了業務邏輯割裂。

三 沒必要要的消息機制
在使用redux框架的項目中，涉及到store中數據更新的都須要經過發送一個action觸發，這是一種典型的消息機制驅動的軟件系統設計。消息機制在大型項目中解藕不一樣模塊，提升可測試性和可擴展性方面都有不錯的表現，但在一些小型項目中確沒有起到什麼本質性的幫助，反而須要開發者建立不一樣類型的action並定義action中payload的格式，增長了業務開發的總體流程。redux的本質是一個數據流管理工具，action的引入讓系統毫無選擇的被設計成消息機制驅動，對開發者不太友善。

四 強制語法
redux的reducer的寫法必須符合特定的格式，即每一個reducer函數都必須返回一個新的對象。咱們翻看一下源碼不難發現，做者在這裏才做用了比較對象地址來進行判斷，以下所示。這種強制的語法不只開銷巨大，一樣對開發者不太友善，一旦忘記這個約束就會形成業務邏輯錯誤。

for (var _i = 0; _i < finalReducerKeys.length; _i++) {
  var _key = finalReducerKeys[_i];
  var reducer = finalReducers[_key];
  var previousStateForKey = state[_key];
  var nextStateForKey = reducer(previousStateForKey, action);
  if (typeof nextStateForKey === 'undefined') {
    var errorMessage = getUndefinedStateErrorMessage(_key, action);
    throw new Error(errorMessage);
  }
  nextState[_key] = nextStateForKey;
  hasChanged = hasChanged || nextStateForKey !== previousStateForKey;
}

五 龐大的計算開銷
咱們繼續查看上面的redux源碼，當一個action被dispatch出去後，reducer是如何被執行的呢？注意到源碼中遍歷了全部的reducer並逐個比較返回的對象有沒有改變。這就意味着任何一個action都會觸發全部的reducer被執行一次，其中的計算開銷是顯而易見的。

六 陡峭的學習曲線
redux做爲一個前端數據流框架，內容較多，學習成本是相對較高的。redux中的store和reducer的使用方式是典型的函數式編程的方法，這對於習慣了面向對象編程的開發者來講須要必定的學習成本。此外action這種消息類型的開發模式對於前端開發者來講也相對陌生，須要必定的學習時間。

七 不成熟的生態
目前圍繞redux的相關技術比較多，主要都是redux的一些中間件，好比： redux-promise、redux-observable、saga等等。redux-promise、redux-observable都能解決異步數據的問題，但對業務開發的實質性幫助並不大。saga雖然功能強大但相對較重並且目前主要使用的僅僅是side effects部分。整體來講圍繞redux的相關框架都不是特別成熟，尚不能對業務開發起到很是大的幫助。

結尾
上文總結了redux的「七宗罪」，前端數據流框架的核心任務就是管理組件之間須要共享的數據，及時觸發組件的從新渲染，這點在現在的前端架構中是很是重要的一環。redux的store可以很好的完成這一點，但引入reducer和action卻帶來了不少問題，下降了項目總體開發效率。那麼一個合格的數據流框架究竟應該是怎樣的呢？在下一篇文章中我會詳細介紹個人解決方案－Hytex框架。