在一個龐大的商業系統中引入react這種數據驅動的模式。
但願可以一點點重構去替換之前的模塊,逐步的將系統重要部分底層框架替換成react。前端
如下內容都摘自同事使用後的一些感想react
心得一jquery
從過程化開發向面向數據的開發轉化。後者要求開發者對數據結構和算法和業務需求自己要有理解。React開發的核心是設計一套數據結構使其既方便業務用戶界面的展現又能方便的實現業務功能——表現爲一組操做數據結構的算法。這與傳統的前端開發很不同,偏激一點的說,相比之前用$搬弄DOM節點,我以爲這樣的前端開發更「嚴肅」了。我但願可以推進團隊迎接,適應,實現這個變化,這對於一個技術人員,而不只僅是前端技術人員都是有益的。算法
心得二編程
1.React單向數據流原則是核心中的核心,即整個系統中只存在自上至下的數據流,反向數據流經過綁定自動完成,不存在兄弟間橫向數據流。微信
2.控制數據流屬於最強的開發規範,一定會給開發業務的同窗帶來巨大的思惟挑戰,從系統總體質量和維護性來看,必須犧牲業務開發的編程自由度。目前就是自由度過高,致使出現五花八門的業務實現,代碼根本無法看。數據結構
心得三框架
其實以前咱們也是數據驅動視圖的,生命週期時用初始化數據渲染了視圖,天然這時有了一層數據到視圖的映射邏輯關係。數據改變以後綁定視圖映射關係會寫在model onchange handler中。數據結構和算法
這樣會有一些問題:性能
1.數據到設圖的映射邏輯關係可能寫了兩遍,並且會發散在template, action, view等各個地方
2.初始化時數據和視圖的關係是同步的,可是初始化以後這二者就可能就不一致,極可能handler沒寫用jquery直接操做DOM了。
初級階段以爲React的好處是,把映射關係收斂到render方法中,有一層封裝讓咱們直接操做DOM變得更難。數據若是在任什麼時候候都能表達視圖,是有不少事情能夠想象的。
心得四
咱們須要在React方面思考的技術問題,有下面這些點:
UI組件應當有穩定一致的開發規範。
UI組件應當有充分的UT 。(並嘗試是否能夠爲業務組件加UT)
UI組件乃至業務組件內的數據結構是否應該有一個統一的模式(如immutable或者更輕量的模式),使得對於數據結構的任意位置的修改,均可以有事件冒出作一些統一的處理。
多個兄弟的組件之間的通訊有什麼範式?
父子組件之間雙向通訊有什麼範式?
目前實現了ER-React,即一個React模塊對外表現爲一個ER模塊。將來在此基礎上,將一個ER-React模塊的父模塊實現爲React後,是要脫掉ER-React的ER,變爲React-React呢?仍是實現爲React-ER-React呢?
按照React的開發模式,隨着咱們自下而上的重構業務,很天然的,下面的組件的「Model」部分會逐漸「上浮「與上層的組件的Model合併成爲一個更大的Model。如此往復,咱們天然會造成「整個應用只有一個大Model」的局面。咱們須要在這一切發生以前想明白這個「大Model」內部要如何組織,會以何種形式存在,並以何種形式和各個組件交互。
相似,從View的角度看,咱們最終會造成「整個應用就是一個大的React組件」。對於每個業務動做,整個應用都會從新render。這個render的性能早晚咱們須要關心。如何控制這個render的性能使之不會影響用戶體驗?
引入後我以爲最重要的成就就是讓一個系統擁有升級換代的活力。就像注入新鮮血液同樣,系統可以跟上時代的變化。
對於一個龐大的商業系統而言,系統底層的穩定性是一個很重要的點。不過若是能在在系統上面作一些侵入性的改造,讓一個穩定的系統充滿活力仍是頗有意義的。
首先對於業務開發人員,很明顯,他們在原有系統上面開發了這麼久之後,對於新技術的引入是很是歡迎的,他們是很是樂意去學習新技術的。
這個是寫給老闆們看的,花這麼大力氣去引入一個新技術對於公司的收益就是提升開發人員的效率。
固然這個提升的效率的前提是對於開發人員有更高的要求的。
react的模式是能夠在某種程度上面融入UT的。
以及一個很好的數據驅動模式維護性和擴展性是比現有系統強的。
數據驅動好處就是能夠經過數據記錄用戶的頁面狀態,用數據就能恢復頁面快照,須要分析用戶行爲,只須要收集到頁面的數據變化流便可。
數據驅動最合適的是從根部重構。可是目前咱們只能從葉子模塊一點點往根部重構。實際上是一個反向過程。
數據驅動模式對於開發人員要求比較高,能不能設計一種模式下降要求,避免出現不一樣水平的開發者開發出層次不齊的業務模塊。
引入新的模式一個缺點就是之前模式成爲了技術債務。由於一個系統存在多種模式,意味着新人學習成本會增長不少。多種模式的共存,若是維護很差,也會出現一種很混亂的現象。
ps:重要開通了微信的打賞功能,你們以爲好的話,去捧個場。。。奉旨打賞^_^