摘要：控制數(shù)據(jù)流屬于最強(qiáng)的開(kāi)發(fā)規(guī)范，必定會(huì)給開(kāi)發(fā)業(yè)務(wù)的同學(xué)帶來(lái)巨大的思維挑戰(zhàn)，從系統(tǒng)整體質(zhì)量和維護(hù)性來(lái)看，必須犧牲業(yè)務(wù)開(kāi)發(fā)的編程自由度。

在一個(gè)龐大的商業(yè)系統(tǒng)中引入react這種數(shù)據(jù)驅(qū)動(dòng)的模式。
希望能夠一點(diǎn)點(diǎn)重構(gòu)去替換以前的模塊，逐步的將系統(tǒng)重要部分底層框架替換成react。

以下內(nèi)容都摘自同事使用后的一些感想

心得一

從過(guò)程化開(kāi)發(fā)向面向數(shù)據(jù)的開(kāi)發(fā)轉(zhuǎn)化。后者要求開(kāi)發(fā)者對(duì)數(shù)據(jù)結(jié)構(gòu)和算法和業(yè)務(wù)需求本身要有理解。React開(kāi)發(fā)的核心是設(shè)計(jì)一套數(shù)據(jù)結(jié)構(gòu)使其既方便業(yè)務(wù)用戶界面的展示又能方便的實(shí)現(xiàn)業(yè)務(wù)功能——表現(xiàn)為一組操作數(shù)據(jù)結(jié)構(gòu)的算法。這與傳統(tǒng)的前端開(kāi)發(fā)很不一樣，偏激一點(diǎn)的說(shuō)，相比以前用$搬弄DOM節(jié)點(diǎn)，我覺(jué)得這樣的前端開(kāi)發(fā)更“嚴(yán)肅”了。我希望能夠推動(dòng)團(tuán)隊(duì)迎接，適應(yīng)，實(shí)現(xiàn)這個(gè)變化，這對(duì)于一個(gè)技術(shù)人員，而不僅僅是前端技術(shù)人員都是有益的。

心得二

1．React單向數(shù)據(jù)流原則是核心中的核心，即整個(gè)系統(tǒng)中只存在自上至下的數(shù)據(jù)流，反向數(shù)據(jù)流通過(guò)綁定自動(dòng)完成，不存在兄弟間橫向數(shù)據(jù)流。
2．控制數(shù)據(jù)流屬于最強(qiáng)的開(kāi)發(fā)規(guī)范，必定會(huì)給開(kāi)發(fā)業(yè)務(wù)的同學(xué)帶來(lái)巨大的思維挑戰(zhàn)，從系統(tǒng)整體質(zhì)量和維護(hù)性來(lái)看，必須犧牲業(yè)務(wù)開(kāi)發(fā)的編程自由度。目前就是自由度太高，導(dǎo)致出現(xiàn)五花八門(mén)的業(yè)務(wù)實(shí)現(xiàn)，代碼根本沒(méi)法看。

心得三

其實(shí)之前我們也是數(shù)據(jù)驅(qū)動(dòng)視圖的，生命周期時(shí)用初始化數(shù)據(jù)渲染了視圖，自然這時(shí)有了一層數(shù)據(jù)到視圖的映射邏輯關(guān)系。數(shù)據(jù)改變之后綁定視圖映射關(guān)系會(huì)寫(xiě)在model onchange handler中。
這樣會(huì)有一些問(wèn)題：
1.數(shù)據(jù)到設(shè)圖的映射邏輯關(guān)系可能寫(xiě)了兩遍，而且會(huì)發(fā)散在template, action, view等各個(gè)地方
2.初始化時(shí)數(shù)據(jù)和視圖的關(guān)系是同步的，但是初始化之后這兩者就可能就不一致，很可能handler沒(méi)寫(xiě)用jquery直接操作DOM了。
初級(jí)階段覺(jué)得React的好處是，把映射關(guān)系收斂到render方法中，有一層封裝讓我們直接操作DOM變得更難。數(shù)據(jù)如果在任何時(shí)候都能表達(dá)視圖，是有很多事情可以想象的。

心得四

我們需要在React方面思考的技術(shù)問(wèn)題，有下面這些點(diǎn)：
UI組件應(yīng)當(dāng)有穩(wěn)定一致的開(kāi)發(fā)規(guī)范。
UI組件應(yīng)當(dāng)有充分的UT 。（并嘗試是否可以為業(yè)務(wù)組件加UT）
UI組件乃至業(yè)務(wù)組件內(nèi)的數(shù)據(jù)結(jié)構(gòu)是否應(yīng)該有一個(gè)統(tǒng)一的模式（如immutable或者更輕量的模式），使得對(duì)于數(shù)據(jù)結(jié)構(gòu)的任意位置的修改，都可以有事件冒出做一些統(tǒng)一的處理。
多個(gè)兄弟的組件之間的通信有什么范式？
父子組件之間雙向通信有什么范式？
目前實(shí)現(xiàn)了ER-React，即一個(gè)React模塊對(duì)外表現(xiàn)為一個(gè)ER模塊。未來(lái)在此基礎(chǔ)上，將一個(gè)ER-React模塊的父模塊實(shí)現(xiàn)為React后，是要脫掉ER-React的ER，變?yōu)镽eact-React呢？還是實(shí)現(xiàn)為React-ER-React呢？
按照React的開(kāi)發(fā)模式，隨著我們自下而上的重構(gòu)業(yè)務(wù)，很自然的，下面的組件的“Model”部分會(huì)逐漸“上浮“與上層的組件的Model合并成為一個(gè)更大的Model。如此往復(fù)，我們自然會(huì)形成“整個(gè)應(yīng)用只有一個(gè)大Model”的局面。我們需要在這一切發(fā)生之前想明白這個(gè)“大Model”內(nèi)部要如何組織，會(huì)以何種形式存在，并以何種形式和各個(gè)組件交互。
類似，從View的角度看，我們最終會(huì)形成“整個(gè)應(yīng)用就是一個(gè)大的React組件”。對(duì)于每一個(gè)業(yè)務(wù)動(dòng)作，整個(gè)應(yīng)用都會(huì)重新render。這個(gè)render的性能遲早我們需要關(guān)心。如何控制這個(gè)render的性能使之不會(huì)影響用戶體驗(yàn)？

引入后我覺(jué)得最重要的成就就是讓一個(gè)系統(tǒng)擁有升級(jí)換代的活力。就像注入新鮮血液一樣，系統(tǒng)能夠跟上時(shí)代的變化。

對(duì)于一個(gè)龐大的商業(yè)系統(tǒng)而言，系統(tǒng)底層的穩(wěn)定性是一個(gè)很重要的點(diǎn)。不過(guò)如果能在在系統(tǒng)上面做一些侵入性的改造，讓一個(gè)穩(wěn)定的系統(tǒng)充滿活力還是很有意義的。

首先對(duì)于業(yè)務(wù)開(kāi)發(fā)人員，很明顯，他們?cè)谠邢到y(tǒng)上面開(kāi)發(fā)了這么久以后，對(duì)于新技術(shù)的引入是非常歡迎的，他們是非常樂(lè)意去學(xué)習(xí)新技術(shù)的。

這個(gè)是寫(xiě)給老板們看的，花這么大力氣去引入一個(gè)新技術(shù)對(duì)于公司的收益就是提高開(kāi)發(fā)人員的效率。

當(dāng)然這個(gè)提高的效率的前提是對(duì)于開(kāi)發(fā)人員有更高的要求的。

react的模式是可以在某種程度上面融入U(xiǎn)T的。
以及一個(gè)很好的數(shù)據(jù)驅(qū)動(dòng)模式維護(hù)性和擴(kuò)展性是比現(xiàn)有系統(tǒng)強(qiáng)的。

數(shù)據(jù)驅(qū)動(dòng)好處就是可以通過(guò)數(shù)據(jù)記錄用戶的頁(yè)面狀態(tài)，用數(shù)據(jù)就能恢復(fù)頁(yè)面快照，需要分析用戶行為，只需要收集到頁(yè)面的數(shù)據(jù)變化流即可。

數(shù)據(jù)驅(qū)動(dòng)最合適的是從根部重構(gòu)。但是目前我們只能從葉子模塊一點(diǎn)點(diǎn)往根部重構(gòu)。其實(shí)是一個(gè)反向過(guò)程。

數(shù)據(jù)驅(qū)動(dòng)模式對(duì)于開(kāi)發(fā)人員要求比較高，能不能設(shè)計(jì)一種模式降低要求，避免出現(xiàn)不同水平的開(kāi)發(fā)者開(kāi)發(fā)出層次不齊的業(yè)務(wù)模塊。

引入新的模式一個(gè)缺點(diǎn)就是以前模式成為了技術(shù)債務(wù)。因?yàn)橐粋€(gè)系統(tǒng)存在多種模式，意味著新人學(xué)習(xí)成本會(huì)增加很多。多種模式的共存，如果維護(hù)不好，也會(huì)出現(xiàn)一種很混亂的現(xiàn)象。

ps:重要開(kāi)通了微信的打賞功能，大家覺(jué)得好的話，去捧個(gè)場(chǎng)。。。奉旨打賞^_^