【js】爲何要使用react+redux

　　前端的浪潮一疊疊襲來，帶走了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.js
createStore.js
compose.js
combineReducers.js
bindActionCreators.js
applyMiddleware.js

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

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

　　一個是有關數據統計和異步請求的代碼究竟應該寫在哪的問題。不一樣的業務場景不一樣的人，不一樣的實際狀況，頗有可能會讓咱們在實際操做時，將action和reducer混淆使用，這樣原本是爲了下降維護成本而剝離產生的action卻增長了咱們的額外成本，這實際上是得不償失的。

　　另外一個是關於狀態注入時狀態的多少問題。注入少了，以後的需求變動又須要頻繁改變代碼，注入多了又會致使組件的頻繁更新，且注入方式至關的隨意，對後續維護也是一件很是吃力的事情。。。

　　其實這樣的例子還有不少，歸根結底redux是一種思想，並且仍是一種很靈活的思想，它給了使用者很大的自由發揮的空間，可是在社會化的協同工做時，過多的「自由」卻又意味着「不自由」。　

　　其實時代的變遷，歷史的演進，新舊事物的交替實際上是提現了人類思惟方式的變化和麪對的場景的變化。當初咱們只須要dom操做就能完成頁面，因此jQuery就足夠了，可是如今隨着前端的不斷髮展，體驗要求、功能要求愈來愈高，愈來愈多，原始的簡單頁面維度的應用已經不能知足了，因而，react或者其餘的類virtual庫纔會應運而生，而後新問題出現了，再去造新的輪子，而後，歷史也便造成了。

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