摘要：七宗罪目前已經(jīng)成為了前端開發(fā)領(lǐng)域內(nèi)較為主流的一種架構(gòu)模式。以下詳細(xì)探討最主要的個問題，簡稱七宗罪。一過多的文件眾所周知由三個部分組成。雖然功能強(qiáng)大但相對較重而且目前主要使用的僅僅是部分。

React+Redux目前已經(jīng)成為了前端開發(fā)領(lǐng)域內(nèi)較為主流的一種架構(gòu)模式。其中React負(fù)責(zé)頁面渲染，Redux負(fù)責(zé)管理所有的業(yè)務(wù)數(shù)據(jù)，如下圖所示。引入redux確實能夠很好的將數(shù)據(jù)與UI解藕，讓React組件做到最大程度的復(fù)用性，但也帶來了很多問題，這些問題都一定程度上降低了業(yè)務(wù)開發(fā)效率。以下詳細(xì)探討redux最主要的7個問題，簡稱“七宗罪”。

一 過多的文件
眾所周知redux由三個部分組成：store、action、reducer。在使用redux時，當(dāng)我們開發(fā)一個頁面，我們就需要定義所有和這個頁面邏輯相關(guān)的action。在處理業(yè)務(wù)數(shù)據(jù)時，我有由需要給每個頁面或者時某種資源定義相應(yīng)的reducer，久而久之，我們的項目里就有了許多action和reducer文件。過多的文件不僅增加了開發(fā)成本還會導(dǎo)致開發(fā)者在進(jìn)行業(yè)務(wù)開發(fā)時不斷的切換文件，降低了開發(fā)效率。

二 業(yè)務(wù)邏輯割裂
redux框架中使用了reducer這一函數(shù)式編程的工具來進(jìn)行數(shù)據(jù)管理，對獲取到的數(shù)據(jù)（用戶通過UI交互產(chǎn)生或后臺數(shù)據(jù)返回）進(jìn)行加工和保存。在前端開發(fā)中的業(yè)務(wù)邏輯一般包含了四個部分：收集數(shù)據(jù)、發(fā)送請求、接收請求、處理數(shù)據(jù)，如下圖所示，這四個步驟一般出現(xiàn)在一個文件里，相對容易修改和維護(hù)。而redux把處理數(shù)據(jù)的邏輯多帶帶抽離出來放入了reducer中，一定程度上增加了業(yè)務(wù)邏輯開發(fā)流程，讓開發(fā)者必須定義好reducer中接受數(shù)據(jù)的格式，并且需要經(jīng)常在不同文件中切換，造成了業(yè)務(wù)邏輯割裂。

三 不必要的消息機(jī)制
在使用redux框架的項目中，涉及到store中數(shù)據(jù)更新的都需要通過發(fā)送一個action觸發(fā)，這是一種典型的消息機(jī)制驅(qū)動的軟件系統(tǒng)設(shè)計。消息機(jī)制在大型項目中解藕不同模塊，提高可測試性和可擴(kuò)展性方面都有不錯的表現(xiàn)，但在一些小型項目中確沒有起到什么本質(zhì)性的幫助，反而需要開發(fā)者創(chuàng)建不同類型的action并定義action中payload的格式，增加了業(yè)務(wù)開發(fā)的整體流程。redux的本質(zhì)是一個數(shù)據(jù)流管理工具，action的引入讓系統(tǒng)毫無選擇的被設(shè)計成消息機(jī)制驅(qū)動，對開發(fā)者不太友善。

四 強(qiáng)制語法
redux的reducer的寫法必須符合特定的格式，即每個reducer函數(shù)都必須返回一個新的對象。我們翻看一下源碼不難發(fā)現(xiàn)，作者在這里才作用了比較對象地址來進(jìn)行判斷，如下所示。這種強(qiáng)制的語法不僅開銷巨大，同樣對開發(fā)者不太友善，一旦忘記這個約束就會造成業(yè)務(wù)邏輯錯誤。

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;
}

五 龐大的計算開銷
我們繼續(xù)查看上面的redux源碼，當(dāng)一個action被dispatch出去后，reducer是如何被執(zhí)行的呢？注意到源碼中遍歷了所有的reducer并逐個比較返回的對象有沒有改變。這就意味著任何一個action都會觸發(fā)所有的reducer被執(zhí)行一次，其中的計算開銷是顯而易見的。

六 陡峭的學(xué)習(xí)曲線
redux作為一個前端數(shù)據(jù)流框架，內(nèi)容較多，學(xué)習(xí)成本是相對較高的。redux中的store和reducer的使用方式是典型的函數(shù)式編程的方法，這對于習(xí)慣了面向?qū)ο缶幊痰拈_發(fā)者來說需要一定的學(xué)習(xí)成本。此外action這種消息類型的開發(fā)模式對于前端開發(fā)者來說也相對陌生，需要一定的學(xué)習(xí)時間。

七 不成熟的生態(tài)
目前圍繞redux的相關(guān)技術(shù)比較多，主要都是redux的一些中間件，比如： redux-promise、redux-observable、saga等等。redux-promise、redux-observable都能解決異步數(shù)據(jù)的問題，但對業(yè)務(wù)開發(fā)的實質(zhì)性幫助并不大。saga雖然功能強(qiáng)大但相對較重而且目前主要使用的僅僅是side effects部分?？傮w來說圍繞redux的相關(guān)框架都不是特別成熟，尚不能對業(yè)務(wù)開發(fā)起到非常大的幫助。

結(jié)尾
上文總結(jié)了redux的“七宗罪”，前端數(shù)據(jù)流框架的核心任務(wù)就是管理組件之間需要共享的數(shù)據(jù)，及時觸發(fā)組件的重新渲染，這點在如今的前端架構(gòu)中是非常重要的一環(huán)。redux的store能夠很好的完成這一點，但引入reducer和action卻帶來了很多問題，降低了項目整體開發(fā)效率。那么一個合格的數(shù)據(jù)流框架究竟應(yīng)該是怎樣的呢？在下一篇文章中我會詳細(xì)介紹我的解決方案－Hytex框架。