【js】為什麼要使用react+redux

標籤：缺點   http   simple   替換   span   前端   公司   bind   技術   

　　前端的浪潮一疊疊襲來，帶走了jQuery，帶走了backbone，帶來了react，帶來了redux，但是面對層出不窮的前端技術，我們應該何去何從呢？近一年來筆者的也發生了同樣的變化，技術棧從.net+backbone+requirejs+grunt變成了nodejs+react+webpack+gulp，一系列的變化也讓筆者對整個過程，整個閉環的工具鏈有了一些自己的感受和理解，於是有了今天此文。

　　其實react出現得很早，但是筆者所在的喚作“大象轉身”的大公司，所以內部技術的迭代，並不像業務迭代那麼的頻繁，畢竟大多數公司奉行的依舊是技術為商務服務的原則（誠然，技術沒有經濟利益的產出，則沒有理由不信奉，不過這又是另一個話題，權且按下不表）。不過也就在去年，筆者由於一些工作上的變動，開始全面的接觸起了react起來，於是念上心頭，我們為什麼要用react呢？

　　其實，談到react，可能最先映入眼帘的就是它對於dom的託管，virtual dom技術的出現也一定程度上封裝了之前紛繁複雜的dom操作，而且也降低了使用門檻（有關瀏覽器內部渲染原理），雖然這也是有副作用的，但是它相較於backbone，省去了大量的dom互動的過程，對於每位前端er都是一件很了不起的事情；不過，相比之下，筆者其實更中意它的設計中的資料流的思想，資料能夠受到約束之後，頁面的狀態不再像之前的時代那麼混亂無序，一切歸於平靜是多麼美好的一件事情。。但是，這種好日子其實並不長久，在應付小規模應用的時候，有約束的資料流向和傳輸也許並沒有什麼副作用，但是項目規模擴大之後，一級一級的狀態/屬性傳輸卻顯得特別的臃腫和低效，如：

　　

　　當我們的組件樹只有1層或者2層的時候，想從最上層透傳屬性還是很容易的事情，但是當組件層級越來越多，比如，從底層父組件傳遞屬性到達最末的葉子組件，整個過程的傳輸在代碼上就顯得相當的冗餘，而且如果多個組件依賴於一個共同的屬性，局部變化引起的全域變化很容易又會導致狀態震蕩，這也是令人倍感頭疼的問題，所以redux就應運而生。

　　react官方最先推出的方案是flux，隨後見賢思齊的將其替換為了redux。其實react中強調的單向資料流幾乎是需要依託redux才能實現的，當接入了redux之後，整個資料流動就變成了以下這個樣子:

　　

　　所有的狀態變化都拘束到reducer(s)中進行，修改統一的資料來源，然後再自上而下的重新分發，減少狀態/屬性傳遞的成本，也從根源上杜絕了狀態震蕩，而且redux將資料從react中分離，則理論上所有的react component都可以是無狀態組件，那麼渲染效能還能夠得到進一步的提升。

　　看到這麼精巧的設計，筆者饒有興緻的研究了一下源碼，並且嘗試著自己也實現了一個簡單的redux，其實redux的源碼也非常的簡潔：

index.jscreateStore.jscompose.jscombineReducers.jsbindActionCreators.jsapplyMiddleware.js

　　主要檔案一共就6個，用得最多的就是createStore和引用了職責鏈模式的applyMiddleware，createStore中大量的體現了函數式編程的思想，剛開始讀起來確實有些吃力，而且js似乎並不是一個很好的實現函數式編程的語境，不過瑕不掩瑜，短短百行不到的代碼，卻解決了react沒能解決的一個很棘手的問題，這也確實是令人驚訝的；另外，相信使用過koa的同學對於職責鏈模式其實並不陌生，特別是還看到了那個蜜汁compose，那種剝洋蔥的調用結構極大的提高了我們在nodejs 寫webservice時的擴充性，也跟我們後續的維護提供了一定的便利。

　　不過本文意並不在介紹它們的內部原理，讓我們回到正題。說了一大堆redux的優點，那麼它有沒有缺點呢？誠然，事無絕對，必有正反。雖然redux提供了很大的方便也彌補了react的一些機制不足，在技術方案上，似乎並沒有什麼問題，但是在實際使用時，由於它自身的鬆散耦合的特性，導致了實現具體功能時多種多樣的方式，而不同的人的理解又會導致不同的實現，舉兩個筆者所在的團隊的例子：

　　一個是有關資料統計和非同步請求的代碼究竟應該寫在哪的問題。不同的業務情境不同的人，不同的實際情況，很有可能會讓我們在實際操作時，將action和reducer混淆使用，這樣本來是為了降低維護成本而剝離產生的action卻增加了我們的額外成本，這其實是得不償失的。

　　另一個是關於狀態注入時狀態的多少問題。注入少了，之後的需求變更又需要頻繁改變代碼，注入多了又會導致組件的頻繁更新，且注入方式相當的隨意，對後續維護也是一件非常吃力的事情。。。

　　其實這樣的例子還有很多，歸根結底redux是一種思想，而且還是一種很靈活的思想，它給了使用者很大的自由發揮的空間，但是在社會化的協同工作時，過多的“自由”卻又意味著“不自由”。　

　　其即時代的變遷，曆史的演化，新舊事物的交替其實是提現了人類思維方式的變化和面對的情境的變化。當初我們只需要dom操作就能完成頁面，所以jQuery就足夠了，但是現在隨著前端的不斷髮展，體驗要求、功能要求越來越高，越來越多，原始的簡單頁面維度應用已經不能滿足了，於是，react或者其他的類virtual庫才會應運而生，然後新問題出現了，再去造新的輪子，然後，曆史也便形成了。

　　但我們仔細想來，就會發現，我們所造之物，其實永遠都不是一個囊括所有問題答案的方案，我們給出的，不過是針對某一個曆史時期的某一個情境的某一個局部最優解而已，問題在變化，答案也在變化，不變的，也許只有時間亙古不變的流逝，以及我們那顆需要永遠保持運動變化的心。

 

　　

【js】為什麼要使用react+redux