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

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

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

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

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

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

挑戰。軟件領域里沒有銀彈，有好處一定有挑戰。

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

輕Component：React的component強調pure render，把業務邏輯放到其它子系統中，如redux中的reducer。

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

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

設計范式是數據驅動組件來render。對比OO范式，OO有時會把compoent搞成自閉的、復雜的類，里面藏了太多的狀態，調測很難跟蹤。

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

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

數據綁定：與數據層（model）綁定數據，展示一個有數據的UI

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

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

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

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

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

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

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

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

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

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

務實：通過JSX來組織表達控件的樹形結構，用this.props來傳遞數據

React是數據驅動式的UI component體系，是一個開放的數據依賴式，非自閉OO對象。它會有以下挑戰

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

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

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

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

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

大組件往往有多個Page，這幾個Page如何交換數據是個很大的挑戰

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

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

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

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

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

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

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

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

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

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

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

接口不超過10個，代碼也非常少，但是與之前的MVC框架完全不同。可能最大的問題是沒有和react-route打通，在工程化時讓人迷茫。?

Redux應用最大的挑戰更多來自設計層面，如何設計action，設計state樹形結構。我們只能通過非常少的線索（FP架構思想）去做，這對沒有FP經驗的團隊是一個大挑戰。

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

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

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

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

FP優缺點

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

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

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

OO優缺點

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

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

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

過度的OO，搞太多java儀式感確實沒有必要。通過架構設計，FP在生產力有著一定的優勢。同時對付復雜系統，能更好調測、定位問題。在新時代下，值得嘗試。

轉載自：http://www.jianshu.com/p/0e42...

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