資訊專欄INFORMATION COLUMN
摘要：它的設(shè)計使得即使是大型團隊也能以高度隔離的方式應(yīng)對功能變更。獲取數(shù)據(jù)數(shù)據(jù)變更性能，都是讓人頭痛的問題。通過維護組件與數(shù)據(jù)間的依賴在依賴的數(shù)據(jù)就緒前組件不會被渲染為開發(fā)者提供更加可預(yù)測的開發(fā)環(huán)境。這杜絕了隱式的數(shù)據(jù)依賴導(dǎo)致的潛在。
關(guān)于Relay與GraphQL的介紹
原文：Introducing Relay and GraphQL
視頻地址（強烈建議觀看）：https://www.youtube.com/watch?v=9sc8Pyc51uU
如今，Web開發(fā)從單純的構(gòu)建界面變得更加接近應(yīng)用（application）。數(shù)據(jù)獲取是一個棘手的問題，特別是當(dāng)應(yīng)用變得復(fù)雜的時候。在React.js Conf上，F(xiàn)acebook公布了兩個項目，用于幫助開發(fā)者簡化數(shù)據(jù)層的問題，即使面對擁有眾多參與者、復(fù)雜得像Facebook一樣的項目。
這兩個項目——Relay和GraphQL——已經(jīng)在Facebook的產(chǎn)品中使用了一段時間了，我們很高興將來能夠把他們貢獻給開源社區(qū)。現(xiàn)在，讓我們先分享一些額外的信息。
什么是RelayRelay是Facebook在React.js Conf（2015年1月）上首次公開的一個新框架，用于為React應(yīng)用處理數(shù)據(jù)層問題。
在Relay中，每個組件都使用一種叫做GraphQL的查詢語句聲明對數(shù)據(jù)的依賴。組件可以使用this.props訪問獲取到的數(shù)據(jù)。
開發(fā)者可以自由地組合React組件，而Relay負責(zé)把不同組件的數(shù)據(jù)查詢語句（原文的query）集中高效地組織并處理，向組件提供精確粒度的數(shù)據(jù)（沒有多余數(shù)據(jù)），當(dāng)數(shù)據(jù)變化時通知相應(yīng)組件更新，并在客戶端維護一份包含所有數(shù)據(jù)的數(shù)據(jù)緩存store。
什么是GraphQLGraphQL是一種用于描述復(fù)雜、嵌套的數(shù)據(jù)依賴的查詢語句。它已經(jīng)在Facebook的原生APP上使用了多年。
在服務(wù)器端，我們通過配置將GraphQL與底層的數(shù)據(jù)查詢代碼映射起來。這層配置使得GraphQL可以訪問不同的底層存儲系統(tǒng)。Relay使用GraphQL作為數(shù)據(jù)查詢語句，但并不指定GraphQL的具體實現(xiàn)。
理念Relay是根據(jù)在Facebook構(gòu)建大型應(yīng)用的經(jīng)驗而誕生的。我們的首要任務(wù)是讓開發(fā)者能以符合直覺的方式構(gòu)建正確、高性能的WEB應(yīng)用。它的設(shè)計使得即使是大型團隊也能以高度隔離的方式應(yīng)對功能變更。獲取數(shù)據(jù)、數(shù)據(jù)變更、性能，都是讓人頭痛的問題。Relay則致力于簡化這些問題，把復(fù)雜的部分交給框架處理，讓開發(fā)者更加專注于應(yīng)用本身。
將查詢語句放到視圖層代碼中，開發(fā)者只需查看組件本身的代碼就可以輕易理解組件的行為：不需要考慮和理解組件所處的上下文。組件可以在任何地方重用，而不用修改它的父組件或服務(wù)器端代碼為它傳遞或準(zhǔn)備數(shù)據(jù)。
譯者注：上圖在原博中沒有，為視頻中截下來的代碼截圖，展示了Relay的query與展示代碼混雜，圖中黃色部分既為GraphQL語句。
代碼混雜（原文為Co-location，意為將數(shù)據(jù)查詢語句放在視圖組件代碼中）將開發(fā)者帶入了“幸福的坑”(猜測此處的“坑”是指這種混雜看起來像是反模式)，他們可以細粒度地獲取需要的數(shù)據(jù)字段，而對粒度的聲明就在視圖層代碼上。這意味著性能自然地得到了提升（更難獲取冗余數(shù)據(jù)），而組件變得更加健壯（同樣得益于顯式的數(shù)據(jù)依賴聲明，字段缺失的情況也得以避免，組件不會在運行時因為渲染缺失的字段而掛掉）。
Relay通過維護組件與數(shù)據(jù)間的依賴——在依賴的數(shù)據(jù)就緒前組件不會被渲染——為開發(fā)者提供更加可預(yù)測的開發(fā)環(huán)境。另外，數(shù)據(jù)查詢語句是靜態(tài)聲明的（換句話說，我們可以在渲染前抽離分析整個組件樹的查詢語句），而GraphQL語法提供了對有效數(shù)據(jù)的準(zhǔn)確描述，因此我們可以通過校驗數(shù)據(jù)查詢語句來盡早地發(fā)現(xiàn)開發(fā)者所犯的錯誤。
組件只能訪問在數(shù)據(jù)查詢語句中聲明過的字段，即使其它字段已經(jīng)被緩存在數(shù)據(jù)Store中（其它組件可能需要這些字段）。這杜絕了隱式的數(shù)據(jù)依賴導(dǎo)致的潛在bug。
通過統(tǒng)一的抽象來處理所有的數(shù)據(jù)獲取工作，我們得以處理很多在應(yīng)用中普遍而重復(fù)的問題：
性能： 所有的查詢都經(jīng)過框架統(tǒng)一處理，否則會變得非常低效。重復(fù)的查詢會被自動合并并批處理成高效的、最小化的。同樣地，框架知道哪些數(shù)據(jù)之前被請求過，或者哪些請求正在進行當(dāng)中，因此數(shù)據(jù)查詢可以自動去重至最小化。
監(jiān)聽： 所有的數(shù)據(jù)都存放在唯一的Store中，對該Store的讀取也由框架管理。這意味著框架了解哪個組件關(guān)心哪些數(shù)據(jù)，數(shù)據(jù)變化時哪些組件應(yīng)該重新渲染；組件不再需要自行監(jiān)聽數(shù)據(jù)更新。
公共范式： 可以更容易地構(gòu)造公共范式。在大會上 Jing給出的例子是分頁：如果你在初始狀態(tài)有10條記錄，翻頁意味著聲明你總共需要15條數(shù)據(jù)（注：每頁5條記錄，這兒的翻頁類似于下拉刷新，新數(shù)據(jù)append到當(dāng)前的后面），框架會分析出你需要和數(shù)據(jù)和現(xiàn)有數(shù)據(jù)之間的差值并構(gòu)建最小查詢，然后在服務(wù)器返回數(shù)據(jù)時更新視圖。
簡化服務(wù)器端： 相比于分散的響應(yīng)端點（響應(yīng)每個action，每個路由項），GraphQL接口可以作為底層資源對外的統(tǒng)一門面
統(tǒng)一處理數(shù)據(jù)變更： Relay有統(tǒng)一的處理數(shù)據(jù)變更（寫數(shù)據(jù)）的模式，在概念上它被抽象成了數(shù)據(jù)查詢模型。你可以理解成一次數(shù)據(jù)變更由兩條數(shù)據(jù)查詢語句組成：一條是帶有副作用的——你提供描述變更的變量（例如：往一條記錄中添加一條評論），另一條則指明了當(dāng)變更完成后更新View視圖所需要的數(shù)據(jù)（例如：評論總數(shù)），然后數(shù)據(jù)像正常的數(shù)據(jù)流一樣被框架處理。我們可以樂觀地立即渲染客戶端，即在假設(shè)數(shù)據(jù)變更成功的前提下更新視圖，在最后提交更新，如果服務(wù)器端返回異常則嘗試重試或回滾視圖。(注：此段翻譯不是太有信心，原文的表述看得不怎么明白)
與Flux的關(guān)系在某些方面Relay的靈感來自于Flux，但是理論模型變得更加簡化。Relay用緩存所有GraphQL數(shù)據(jù)的唯一的store代替了Flux中分散的store；相對于Flux由組件自行監(jiān)聽數(shù)據(jù)變更，Relay用框架管理數(shù)據(jù)訂閱和視圖更新。 Instead of actions, modifications take the form of mutations
在Facebook，我們有完全使用Flux的項目，有完全使用Relay的項目，也有兩者兼用的項目。一個我們逐漸意識到的模式是讓Relay管理應(yīng)用級的數(shù)據(jù)流，而讓Flux管理數(shù)據(jù)之外的應(yīng)用狀態(tài)。
開源計劃我們正在努力讓GraphQL（一個特殊的，參考級的實現(xiàn)）和Relay早日開源（暫時還沒有明確的時間，但我們對于達成這一點非常興奮）。
同時，我們會以博客（還有其它頻道）的形式提供越來越多的信息。隨著我們距離公布開源版本越來越近，你可以期待更多的細節(jié)、語法和API描述等等。
走著瞧吧
譯者后記：之前有看過Flux的相關(guān)資料，也試著自己寫過基于Flux的框架和demo，但總覺得Flux更像一個半成品：對服務(wù)器端交互的問題沒有很好地回答，手工訂閱的action必定會面臨膨脹等……
Relay像是Flux進一步成熟和發(fā)展的產(chǎn)物，某種程度上說甚至有了Angular的影子：更細粒度的聲明式的數(shù)據(jù)依賴管理，框架監(jiān)聽處理數(shù)據(jù)變化。
目前的資料還比較少，很多問題需要等待更進一步的資料或代碼才能弄明白，不過Relay可以說是繼Flux后往前走的一大步，非常值得繼續(xù)關(guān)注
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://specialneedsforspecialkids.com/yun/85537.html
摘要：包括什么把關(guān)于數(shù)據(jù)獲取的事情都接管過來，比如說請求異常，，請求排隊，，獲取分頁數(shù)據(jù)。的聲明式數(shù)據(jù)獲取是按組織的，最好的方式也是把需要的數(shù)據(jù)寫在。另外，通過聲明式數(shù)據(jù)獲取還可以更好的對組件約束，只能獲取它聲明的數(shù)據(jù)，并且也可以做些驗證。 Facebook 在去年夏天公布了 GraphQL，就像往前端深潭砸下了一顆巨石，人們都被水聲吸引到了湖邊，觀望是否會出現(xiàn)什么，有些人期待，有些人猜疑。...
摘要：在一個應(yīng)用中，如何通過和端進行交互這個問題曾經(jīng)困擾了我一段時間，經(jīng)過學(xué)習(xí)實踐，有了一點心得體會，寫出來和大家分享一下。組件和一樣，和進行交互，將獲取的通過向下傳遞給組件。不足被設(shè)計用來和服務(wù)器一起運行，并不能很好的和第三方服務(wù)交互。 在一個react應(yīng)用中，如何通過ajax和server端進行交互這個問題曾經(jīng)困擾了我一段時間，經(jīng)過學(xué)習(xí)實踐，有了一點心得體會，寫出來和大家分享一下。 總的...
摘要：閱讀過程中如果產(chǎn)生任何不適，請及時撥打自行搶救，謝謝。端選型總體還是比較前后端分離的，不強制你使用某一種方案。是官方出品和推薦的，也是默認的配套方案。事后來看，的坑不少。 apollo-client 是一個比較難用的 GraphQL 客戶端，本系列帶你集成 redux，趟平深坑，鉆入原理，讓你在 21 分鐘內(nèi)學(xué)完 apollo-client。 NOTE: 閱讀過程中如果產(chǎn)生任何不適，請...
摘要：作者滬江前端開發(fā)工程師本文原創(chuàng)翻譯，有不當(dāng)?shù)牡胤綒g迎指出。管理數(shù)據(jù)，而提供服務(wù)器上的數(shù)據(jù)，因此應(yīng)用于處理網(wǎng)絡(luò)請求。結(jié)論使用建立的應(yīng)用都是模塊化的會成為其中一個模塊，庫是另一個模塊。原文原創(chuàng)新書移動前端高效開發(fā)實戰(zhàn)已在亞馬遜京東當(dāng)當(dāng)開售。 作者：Oral （滬江Web前端開發(fā)工程師）本文原創(chuàng)翻譯，有不當(dāng)?shù)牡胤綒g迎指出。轉(zhuǎn)載請指明出處。 當(dāng)你問起有關(guān)AJAX與React時，老司機們首先就會...
摘要：譯者按最近依舊如火如荼相信大家都躍躍欲試我們團隊也開始在領(lǐng)域有所嘗試年應(yīng)該是逐漸走向成熟的一年讓我們一起來看看國外的開發(fā)者們都總結(jié)了哪些最佳實踐年在全世界都有很多關(guān)于新的更新和開發(fā)者大會的討論關(guān)于去年的重要事件請參考那么年最有趣的問題來了我 譯者按：最近React(web/native)依舊如火如荼,相信大家都躍躍欲試,我們團隊也開始在React領(lǐng)域有所嘗試. 2016年應(yīng)該是Reac...
閱讀 553·2023-04-26 02:59
閱讀 691·2023-04-25 16:02
閱讀 2154·2021-08-05 09:55
閱讀 3544·2019-08-30 15:55
閱讀 4640·2019-08-30 15:44
閱讀 1797·2019-08-30 13:02
閱讀 2193·2019-08-29 16:57
閱讀 2288·2019-08-26 13:35
