說說React,Flux,Reray和GraghQL

標籤：relay   react   graphql   angularjs   flux   

前幾天看到同事轉寄的《ReactEurope Conf 參會感想》，這篇文章講的react的一些理念感覺有些道理，但我對react最終能很好的實現learn once, write everywhere還是持懷疑態度，畢竟世界是多樣的，Apple的iOS（扁平化風格），Google的Android各自有自己的UI規範（Material Design和AngularJs Material Design ），即使React的理念很好，在別人的地盤上也不一定能弄出多大成果。但在Web前端領域，React作為創新者，必然會推動整個前端開發的進步。

這幾年前端開發領域的快速發展，個人感覺主要有幾個原因：互連網行業對使用者體驗的高要求和前端項目的複雜化，導致以前基於jquery架構和外掛程式的前端代碼逐漸複雜化，跟不上需求的快速變化，代碼膨脹導致維護成為問題，這個是催生新架構的實際需求；前端項目的生命週期相對比較短，一些活動頁面可能就用幾天，一般的主站頁面幾個月也會大改版，相當於伺服器端，前端的曆史包袱少，工程師更可能傾向於使用新技術提供開發效率；互連網的原住民90後開始寫代碼了，這部分人可能很多是從前端入手開發的，他們更喜歡從國外引入新的架構。這也是React現在很熱的一個原因。

我感覺現在React的問題是目標太大，既要做web前端，還要做做iOS原生頁面，後面還要搞Android原生UI。雖然FaceBook的研發能力挺強，Virtual DOM的概念很好，有點像UI層的JVM了，可是大家都知道，即使是JVM做了十幾年了，還是主要在伺服器上用，目前對跨平台的支援也不是特別理想，而UI領域是更加感性和多樣化的，對UI原生層的依賴相對更複雜，各移動平台有自己的UI規範，並且差別很大，因此VDOM在移動端的前景不容樂觀。就移動端開發來說，ReactVDOM相當於在Apple和Google的地盤上另外建立一種開發方式，以後必然會出現利益博弈。 特別是Android平台情況複雜，各種版本，不同的解析度，各種廠商定製裝置，各種定製UI，很懷疑React後面能不能hold住，我估計React Android 10月份跳票的可能性大。

下面說說Flux架構。Flux 是一個Facebook開發的、利用單向資料流實現的應用架構，用於 React。Flux應用有三個主要的部分組成：發送器、儲存和視圖（React 組件）。現在的Flux架構只是個概念，缺少官方標準實現，第三方的實現又有點亂，就連我們公司都自己弄了個iFlux架構，相關的架構太多，後面必然會統一，一些Flux架構後面肯定會死掉或合并。

相對於AngularJS，React不是一個完整的前端解決方案，很多地方還需要補充，這就對團隊的技術能力提出了要求，而AnguarJS架構相對完善，適合作為整體的前端開發解決方案使用，適合大規模工程化開發。至於AngularJS 2，還是等瀏覽器能普遍支援ES6的時候再考慮吧。

個人感覺後面Relay會逐漸替代Flux。Relay是Facebook在React.js Conf（2015年1月）上首次公開的一個新架構，用於為React應用處理資料層問題。在Relay中，每個組件都使用一種叫做GraphQL的查詢語句聲明對資料的依賴。組件可以使用this.props訪問擷取到的資料。開發人員可以自由地組合React組件，而Relay負責把不同組件的資料查詢語句（原文的query）集中高效地組織並處理，向組件提供精確粒度的資料（沒有多餘資料），當資料變化時通知相應組件更新，並在用戶端維護一份包含所有資料的資料緩衝store。

        最後說下GraphQL。GraphQL是一種用於描述複雜、嵌套的資料依賴的查詢語句。它已經在Facebook的原生APP上使用了多年。在伺服器端，我們通過配置將GraphQL與底層的資料查詢代碼映射起來。這層配置使得GraphQL可以訪問不同的底層儲存系統。Relay使用GraphQL作為資料查詢語句，但並不指定GraphQL的具體實現。 

       我覺得GraphQL是一個很好的想法，可能是這一系列項目中後面最有前途的。GraphQL確實解決了REST API的一些痛點，特別是在移動網路環境下介面返回太多冗餘資料的問題，這個問題在目前移動網路流量費還不夠便宜，速度還不夠快的情況下很重要。GraphQL的發展前景是看好的，但目前需要完善生態環境，特別是基於Java的實現架構，Android和iOS的用戶端支援架構，有了這些東西才能真正推動GraphQL的普及，目前僅有node.js版本是遠遠不夠的，畢竟大多數伺服器端項目都不是Node.js的，大多數伺服器端工程師也不精通js。在Android用戶端，已經有大量支援REST的網路情況架構，例如Spring Android，Google Volley等。

      以上文字只是個人看法，至於是否使用React要根據具體的項目和研發團隊情況具體分析。

著作權聲明：本文為博主原創文章，轉載請保留出處http://blog.csdn.net/offbye

說說React,Flux,Reray和GraghQL