?react绞旅、reactjs因悲、react native晃琳、virtual dom卫旱、diff算法顾翼、redux....适贸，按照我的理解取逾，react是大哥砾隅，其他的都是小弟晴埂，頂多是小弟的組長精耐。

react.jpeg

react

作為facebook開源出來的一門技術(shù)，以及現(xiàn)在的流行程度惊完，其價值是不言而喻的小槐。react我覺得它是思想凿跳，一種解決方案控嗜，他將傳統(tǒng)的dom進(jìn)行了抽象躬审，然后通過操作抽象的實例來實現(xiàn)對dom的操作。從事了一段時間angularjs的開發(fā)后發(fā)現(xiàn)博助，組件化的重要性富岳，無論是從維護(hù)層面窖式，還是結(jié)構(gòu)層面萝喘，組件化都是一個非常好的實現(xiàn)爬早。你不用因為修改一點點的地方而去熟悉整個系統(tǒng)筛严，整個功能桨啃，而react就是這樣的优幸。當(dāng)然google團(tuán)隊后面有出了性能更加強(qiáng)大的angular羹饰，同樣的也是將組件化的思想最大化的實現(xiàn)队秩。

virtual dom

然后說一下這個東西筒主，前面說到了react是以抽象dom的方式來操作dom的乌妙，virtual dom就是也就是這個抽象的具體定義。作為react實現(xiàn)的核心之一熊经，抽象dom使得react的實現(xiàn)成為可能匹涮，同時呢也是react的特點之一然低。VTree模型非常簡單灼卢，基本結(jié)構(gòu)如下：

{
?// tag的名字
?tagName: 'p',
?// 節(jié)點包含屬性
?properties: {
??style: {
???color: '#fff'
??}
?},
?// 子節(jié)點
?children: [],
?// 該節(jié)點的唯一表示，后面會講有啥用
?key: 1
}

diff算法

差異算法涩咖，這里應(yīng)該說簡單差異算法，怎么說闸昨，標(biāo)準(zhǔn)的diff算法復(fù)雜度是(n^3)，而這里的dom diff算法復(fù)雜度是(n)循诉。那么React是如何取巧的呢？
1、分層對比

domDiffLayer.jpg

如圖，React僅僅對同一層的節(jié)點嘗試匹配，因為實際上退敦，Web中不太可能把一個Component在不同層中移動瓮下。
2、基于key來匹配

domDiffKey.jpg

還記得之前在VTree中的屬性有一個叫key的東東么？這個是一個VNode的唯一識別，用于對兩個不同的VTree中的VNode做匹配的抵屿。這也很好理解，因為我們經(jīng)常會在Web遇到擁有唯一識別的Component（例如課程卡片、用戶卡片等等）的不同排列問題誉帅。
3档插、基于自定義元素做優(yōu)化

domDiffComponents.jpg

React提供自定義元素氛悬，所以匹配更加簡單棍现。
由于diff操作已經(jīng)找出兩個VTree不同的地方，只要根據(jù)計算出來的結(jié)果，我們就可以對DOM的進(jìn)行差異渲染赤拒。

reactJs.jpeg

reactjs

前面說了這么多肋乍，reactjs也就很好理解了锚烦，實際上它就是react思想的一種實現(xiàn)，可以類比與jquery涮俄、angular之類的實現(xiàn)蛉拙，具體的語法在這里就不做過多的闡述了。

reactNative.jpeg

react native

如果說reactjs面對的是web工程彻亲，那么react native則是面向原生應(yīng)用孕锄。前幾年興起了android和ios，很多人投入到里面苞尝，android和ios也取得了前所未有的成功畸肆。但是，隨著時間的推移宙址，越來越多的問題顯現(xiàn)出來轴脐，學(xué)習(xí)曲線陡峭，開發(fā)抡砂、維護(hù)成本高...大咱。所以有人就希望用前端技術(shù)來代替，實現(xiàn)java所謂的“一次編寫注益，到處運(yùn)行”的宏大目標(biāo)徽级。可是因為局限性聊浅，java虛擬機(jī)擁有的性能是瀏覽器引擎所不能比擬的餐抢，再如多線程的問題也是前端技術(shù)的一個瓶頸现使，要想實現(xiàn)統(tǒng)一，那是何其難旷痕。
?這無非就是三個想法：
1碳锈、在原生里面嵌入js，即webview欺抗，而實際上這完全不能達(dá)到原生的效果售碳；
2、移植React的原生版本绞呈，把React移植到原生也是一個好主意贸人。實際上，在iOS平臺上已經(jīng)這么做了佃声，這個項目叫做ComponentKit艺智。不過這個方案也有幾處不太重要的負(fù)面影響。首先圾亏，它是iOS獨(dú)有的十拣，所以如果我們想在Android上獲得一樣的好處，我們只能去創(chuàng)造一個獨(dú)立的實現(xiàn)志鹃，然后教會工程師怎么去用它夭问。并且，我們也沒辦法同時使用我們?yōu)閣eb頂層構(gòu)建的各種工具曹铃，譬如幫助我們解決了規(guī)模性的數(shù)據(jù)獲取的許多痛點的Relay缰趋。最重要的是，我們沒能改善開發(fā)速度中最大的問題——我們還得每次修改之后陕见，重新編譯和構(gòu)建工程秘血。
3、用腳本封裝原生
?如果我們用JavaScript去調(diào)用原生API淳玩，我們應(yīng)當(dāng)能獲得原生平臺的所有強(qiáng)大之處直撤，同時還能享受快速迭代和使用我們現(xiàn)有JavaScript上基礎(chǔ)設(shè)施的好處非竿。不僅如此蜕着，因為基于JavaScript構(gòu)建，我們應(yīng)當(dāng)能使得這樣技術(shù)椇熘跨平臺承匣。這聽起來恰好是我們要的全部，而且毫不意外有成千上萬的框架正在這么干锤悄，然而實際上問題并沒有被直截了當(dāng)?shù)慕鉀Q韧骗。
說了這么多題外話，言歸正傳零聚，react native是什么袍暴？一句話：其實就是針對特定的平臺用react的方式實現(xiàn)的一套框架些侍。

redux

reduxFlow.jpg

redux不是必須的，是一個錦上添花的東西曾經(jīng)有人說過這樣一句話政模。

"如果你不知道是否需要 Redux岗宣，那就是不需要它。"

Redux 的創(chuàng)造者 Dan Abramov 又補(bǔ)充了一句淋样。

"只有遇到 React 實在解決不了的問題耗式，你才需要 Redux 。"

簡單說趁猴，如果你的UI層非常簡單刊咳，沒有很多互動，Redux 就是不必要的儡司，用了反而增加復(fù)雜性娱挨。

用戶的使用方式非常簡單
用戶之間沒有協(xié)作
不需要與服務(wù)器大量交互，也沒有使用 WebSocket
視圖層（View）只從單一來源獲取數(shù)據(jù)

上面這些情況枫慷，都不需要使用 Redux让蕾。

用戶的使用方式復(fù)雜
不同身份的用戶有不同的使用方式（比如普通用戶和管理員）
多個用戶之間可以協(xié)作
與服務(wù)器大量交互，或者使用了WebSocket
View要從多個來源獲取數(shù)據(jù)

上面這些情況才是 Redux 的適用場景：多交互或听、多數(shù)據(jù)源探孝。
從組件角度看，如果你的應(yīng)用有以下場景誉裆，可以考慮使用 Redux顿颅。

某個組件的狀態(tài)，需要共享
某個狀態(tài)需要在任何地方都可以拿到
一個組件需要改變?nèi)譅顟B(tài)
一個組件需要改變另一個組件的狀態(tài)

發(fā)生上面情況時足丢，如果不使用 Redux 或者其他狀態(tài)管理工具粱腻，不按照一定規(guī)律處理狀態(tài)的讀寫，代碼很快就會變成一團(tuán)亂麻斩跌。你需要一種機(jī)制绍些，可以在同一個地方查詢狀態(tài)、改變狀態(tài)耀鸦、傳播狀態(tài)的變化柬批。
總之，不要把 Redux 當(dāng)作萬靈丹袖订，如果你的應(yīng)用沒那么復(fù)雜氮帐，就沒必要用它。另一方面洛姑，Redux 只是 Web 架構(gòu)的一種解決方案上沐，也可以選擇其他方案。