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

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

以下內容都摘自同事使用后的一些感想

心得一

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

心得二

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

心得三

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

心得四

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

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

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

首先對于業(yè)務開發(fā)人員，很明顯，他們在原有系統(tǒng)上面開發(fā)了這么久以后，對于新技術的引入是非常歡迎的，他們是非常樂意去學習新技術的。

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

當然這個提高的效率的前提是對于開發(fā)人員有更高的要求的。

react的模式是可以在某種程度上面融入UT的。
以及一個很好的數(shù)據(jù)驅動模式維護性和擴展性是比現(xiàn)有系統(tǒng)強的。

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

數(shù)據(jù)驅動最合適的是從根部重構。但是目前我們只能從葉子模塊一點點往根部重構。其實是一個反向過程。

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

引入新的模式一個缺點就是以前模式成為了技術債務。因為一個系統(tǒng)存在多種模式，意味著新人學習成本會增加很多。多種模式的共存，如果維護不好，也會出現(xiàn)一種很混亂的現(xiàn)象。

ps:重要開通了微信的打賞功能，大家覺得好的話，去捧個場。。。奉旨打賞^_^