摘要：這對復雜問題定位是有好處的。同時，也是純函數(shù)，與的是純函數(shù)呼應。強約束約定，增加了內(nèi)聚合性。通過約定和全局的理解，可以減少的一些缺點。約定大于配置也是框架的主要發(fā)展方向。

React+Redux非常精煉，良好運用將發(fā)揮出極強勁的生產(chǎn)力。但最大的挑戰(zhàn)來自于函數(shù)式編程（FP）范式。在工程化過程中，架構(gòu)（頂層）設(shè)計將是一個巨大的挑戰(zhàn)。要不然做出來的東西可能是一團亂麻。說到底，傳統(tǒng)框架與react+redux就是OO與FP編程范式的對決。

簡單學習某項技術(shù)并不能讓建立起一個全局理解，也很難工程化。所以，我們必須要看以下幾方面：

了解其獨特的東西。如React中組件是pure render函數(shù)。

置新技術(shù)于上下文中。將React放在flux、redux中。才能真正看到數(shù)據(jù)單向流動。

對比看到優(yōu)勢。比其它的解決方案(vue, angluar，adobe flex），看其優(yōu)勢。

挑戰(zhàn)。軟件領(lǐng)域里沒有銀彈，有好處一定有挑戰(zhàn)。

Virtual Dom：又一個虛擬層、中間層、cache層，大膽的跳出了web的DOM實現(xiàn)約束，實現(xiàn)更加理想的UI編程模型：樹型控件組織、統(tǒng)一事件、統(tǒng)一數(shù)據(jù)傳輸通道(props)。可以把Dom render到web，navtive的GUI系統(tǒng)上，這非常美妙，Learn once, Use Everywhere。

輕Component：React的component強調(diào)pure render，把業(yè)務邏輯放到其它子系統(tǒng)中，如redux中的reducer。

組件狀態(tài)（state）要最小化的，按官方說法，不是props傳入的，隨時間變化的，不能是通過其它的props和stat計算而來。

常用的設(shè)計模式：創(chuàng)建多個只負責渲染數(shù)據(jù)的無狀態(tài)（stateless）組件，在它們的上，是有狀態(tài)（stateful）組件。有狀態(tài)組件封裝了所有用戶的交互邏輯，而這些無狀態(tài)組件則負責聲明式地渲染數(shù)據(jù)。

設(shè)計范式是數(shù)據(jù)驅(qū)動組件來render。對比OO范式，OO有時會把compoent搞成自閉的、復雜的類，里面藏了太多的狀態(tài)，調(diào)測很難跟蹤。

React的virtual DOM想要構(gòu)建一個理想的前端模型，那理想的前端編程到底是如何呢？我個人總結(jié)的4點：

構(gòu)建基本UI能力：不論是組件拖拉（VB），還是寫樹型XML描述文檔，能快速做出和直覺一致的UI界面

數(shù)據(jù)綁定：與數(shù)據(jù)層（model）綁定數(shù)據(jù)，展示一個有數(shù)據(jù)的UI

用戶交互：用戶點擊、觸摸，程序完成業(yè)務邏輯，并反饋給用戶，表明是一個活的UI

UI布局：組織管理合個UI，一個UI調(diào)起另一個UI，自己死掉或藏起來。

構(gòu)建基本UI能力：React完成的非常不錯，通過寫JSX能完成一個基本UI的構(gòu)建。JSX是一個非常好的工程化手段，你第一眼看到它，可難會不爽。但新事物總要給它五分鐘！品味一下，你會發(fā)現(xiàn)這樣做更內(nèi)聚，更務實的把計算與顯示內(nèi)聚在一個地方，甚至你還可以把css樣式以inline sytle的方式寫在js文件里。最重要的是它可以把讓XML化的組件與js完美混合計算！

在數(shù)據(jù)綁定：React通過父子組件的props數(shù)據(jù)通訊協(xié)議，可以漂亮的完成初始數(shù)據(jù)綁定。這個props做得簡單而高效，大亮點！

用戶交互：React組件被認為自己是一個有限狀態(tài)機。與用戶交互，改變自己的狀態(tài)（state）。算法根據(jù)這些狀態(tài)，render算法現(xiàn)計算出合適的數(shù)據(jù)集呈現(xiàn)給用戶。這樣做的好處是設(shè)計范式高度一致。

UI布局，可能需要用到react-router，或者自己寫框架。這一塊還未研究。

React對比其它方案，突出優(yōu)點是正交化、輕、約定性、務實：

正交：對比Vue, Angular更正交化，它沒有template，大的component就是template。

輕：對比abobe flex或其它的UI系統(tǒng)是輕，沒有復雜的UI OO體系，這也是說明React只是一個目標UI體系的粘合層。

約定性：約定大于Java儀式感，這也是自Rails之后在風潮。如pure render，最小化無狀態(tài)state。

務實：通過JSX來組織表達控件的樹形結(jié)構(gòu)，用this.props來傳遞數(shù)據(jù)

React是數(shù)據(jù)驅(qū)動式的UI component體系，是一個開放的數(shù)據(jù)依賴式，非自閉OO對象。它會有以下挑戰(zhàn)

render方法可能很大，component顯示邏輯是一次性在render里實現(xiàn)的。這里往往有兩部分邏輯實現(xiàn)，初次數(shù)據(jù)綁定，與用戶交互之后的算法。

render出一個ReactElement樹，但這個樹中的一些組件、UI元素因為計算被前移了，這會導致這個樹看起來不太完整，進而不太直觀。

雖然可以分解成小的component，構(gòu)建大的Component可能是個挑戰(zhàn)，因為所有邏輯都依賴于外部數(shù)據(jù)，而外部數(shù)據(jù)相對不穩(wěn)定，組件失去了自我邊界的保護，非自閉。

當交互復雜，組件的state也會越來越大，render全局算法會越來越難寫。

把子組件的行為傳上來也是一件不顯化的事，往往需要把父組件的一個函數(shù)作為回調(diào)傳給子組件。

大組件往往有多個Page，這幾個Page如何交換數(shù)據(jù)是個很大的挑戰(zhàn)

一個數(shù)據(jù)層的framework，類似于Baobab。比其好的一點，引入middleware體系，有幾個現(xiàn)成的插件redux-thunk, redux-promise，不用但心異步請求的事。雖然說靈活、獨立很重要，但全局設(shè)計也是 讓人放心去用，而不用擔心功能缺失和其它風險。

應用了FP中數(shù)據(jù)不可變性（immutable），這讓追蹤數(shù)據(jù)改變過程有很大提升。也就是其宣揚的時間旅行。這對復雜問題定位是有好處的。

樹形化數(shù)據(jù)存儲，reducer的返回即是其新建，更新、刪除過程，樹形結(jié)構(gòu)不需要預先定義。同時，reducer也是純函數(shù)，與reactor的render是純函數(shù)呼應。

強約束（約定），增加了內(nèi)聚合性。Flux中的action, dispatcher, store比較散，在分層架構(gòu)是需要的，但內(nèi)聚性不佳，出現(xiàn)java的儀式感。而redux是數(shù)據(jù)層很清晰，一個store，更新則dispatch到action，前半段自己想怎么搞就怎么搞(middleware），后半段reducer。reducer約束是不要改oldState，返回newStatew，做到immutable。

不一樣的action：Redux中的action會切得很細，一個傳統(tǒng)的Action被切成了三個Action：Loading, GetSuccess, GetError。所以，從這個方面來看Action服務于UI，而非業(yè)務邏輯單元。

Redux大量應用FP，經(jīng)常遇到FP中的curry, trund, promise這些概念，學習成本較高。在middleware層實現(xiàn)，對沒有FP經(jīng)驗的人講不友好。

Redux是一個比較薄的數(shù)據(jù)層。同時，把View同步刷新也做了（redux-react）。

在傳統(tǒng)MVC中，還是有一個controller來做業(yè)務邏輯。但Redux硬生生的把一個controller切成二部分:action, reducer。

理論上，Redux還可以把React組件中的stat的存儲也拿過來，比如用戶搜索的名稱。這樣，就可以把過濾算法放到selector中去。但這樣好處并不是很大。

與Baobab對比，兩者都是數(shù)據(jù)管理框架，Baobab提供cursor來方便你對很深層的數(shù)據(jù)結(jié)構(gòu)進行update。而redux是通過selector函數(shù)來做，這種方法會比較晦澀。但比Baobab好的地方，做數(shù)據(jù)fetch可以通過Redux的middleware來完成。

與Rails的controller, ActionRecord相比，Redux更多是一種約定，不提供路由級的controller，不提供數(shù)據(jù)訪問cursor。

接口不超過10個，代碼也非常少，但是與之前的MVC框架完全不同?？赡茏畲蟮膯栴}是沒有和react-route打通，在工程化時讓人迷茫。?

Redux應用最大的挑戰(zhàn)更多來自設(shè)計層面，如何設(shè)計action，設(shè)計state樹形結(jié)構(gòu)。我們只能通過非常少的線索（FP架構(gòu)思想）去做，這對沒有FP經(jīng)驗的團隊是一個大挑戰(zhàn)。

通過selector函數(shù)從stat樹里取數(shù)據(jù)比較晦澀，并且這個selector里的代碼認為是業(yè)務邏輯，多帶帶放在selector，業(yè)務上不內(nèi)聚。

middleware層設(shè)計：action是一個意圖(intent），發(fā)送給middleware，讓其來實現(xiàn)此意圖。但這樣做，action比有兩義性，一會兒是對象，一會兒是函數(shù)。同時FP編程侵入性太大。

沒有與Route結(jié)合起來設(shè)計，讓人很不放心，也不知道如何在不同路由下來做數(shù)據(jù)與組件的connect。

react + redux是一種典型的FP編程范式實現(xiàn)，而其它框架大多是OO范式。是否選用react+redux開發(fā)，需要看是否對FP有掌握或者有一定的架構(gòu)能力。但多帶帶用react則沒有這種要求，當個view來用。

FP優(yōu)缺點

FP的好處是沒有OO的復雜儀式感，是沿著數(shù)據(jù)結(jié)構(gòu)+算法的思路進行抽象和結(jié)構(gòu)化。如果頂層設(shè)計做好，代碼復用度極高，代碼量少。比如要生成一顆樹我用迭歸算法直接生成，而OO的人往往會用一個Composite模式去定義一個晦澀的類接口。

FP的缺點也是也是面向過程編程的缺點，算法與數(shù)據(jù)全局化、并且互相耦合，這往往會導致一個強耦合的系統(tǒng)。如果沒有做好頂層設(shè)計，是難以演進的。

通過約定和全局的理解，可以減少FP的一些缺點?！凹s定大于配置”也是框架的主要發(fā)展方向。?

OO優(yōu)缺點

OO的好處是分而治之，增量演進。同時有自閉性，語義比較清晰。

缺點是在表達一些算法時，反而是很困難的。如command模式實現(xiàn)歷史回滾就挺麻煩。也這是四人幫的設(shè)計模式大多比較難以理解的原因。另外，OO一直有一個對算法復用的問題，ruby語言解決比較好，用mixin很自然。而像C++就用多繼承和泛型，個人感覺并不是最好的。?

有FP經(jīng)驗的或者架構(gòu)能力比較強，團隊人員比較少、能力強，較強適合用react+redux。不然用react+angluar, 或直接用vue。

過度的OO，搞太多java儀式感確實沒有必要。通過架構(gòu)設(shè)計，F(xiàn)P在生產(chǎn)力有著一定的優(yōu)勢。同時對付復雜系統(tǒng)，能更好調(diào)測、定位問題。在新時代下，值得嘗試。

轉(zhuǎn)載自：http://www.jianshu.com/p/0e42...

個人建了前端學習群，旨在一起學習前端。純凈、純粹技術(shù)討論，非前端人員勿擾！入群加我微信：iamaixiaoxiao。