QueryRenderer在繼電器現代中的角色？

Question

所以，首先有點背景。 我是一位本機iOS/Android開發人員，現在開始我的第一個React Native項目。它帶來了Javascript的所有好處和痛苦，但到目前爲止，我非常喜歡它:-)我也決定也第一次嘗試使用GraphQL。

作爲React環境中的新手，我也沒有任何關於Relay的知識，但是在我的創業社區的朋友和我的web-dev同事的推薦中選擇了它。我也被告知學習曲線有些陡峭，但決定繼續前進 - 我已經與JS和一個0.xx版本的新移動平臺進行了艱苦的鬥爭，所以到底什麼是對的？ :-)我設法通過我的GQL服務器正確設置我的項目和衝壓整體帶QueryRenderer，這是一個極大的安慰:-)

因此，在對問題

我很難找出容器/組件的關係，以及容器的組成。閱讀the docs on composition幫助，但我仍然懷疑過的QueryRenderer

• QueryRenderer的角色由文檔據說是每一個接力樹的根容器。這是否意味着我們應用程序中的根應該有QueryRenderer？或者在每個導航路徑的根目錄下（即我們應用程序中的選項卡）？或者只是針對每個容器組件（與表示/啞/純組件相反，React明智）？請注意，我不是在尋找意見，而是最佳實踐的論點:-)
• FragmentContainer（或其他任何容器，就此而言）在「父」組件中的作業沒有QueryRenderer？
• QueryRenderer如何鏈接到子容器？它是否獲取子容器所需的所有數據的總和，然後從高速緩存中讀取子容器，或者？如果是這樣，我誤解了Relay的優點 - 我們覺得每個組件都可以獨立於每個其他組件獲取數據，並且每個組件都不知道其他組件的數據需求（包括父/子組件）。我認爲這個假設也令我對QueryRenderer感到困惑，並且需要一個「根」容器。
• 如果QueryRenderer是中繼樹的「父」/「根」中繼容器，它如何根據請求呈現視圖組件？爲什麼它必須有一個請求？什麼時候應該使用QueryRenderer？

任何幫助深表感謝:-)

Answer 1

因此，在與我們的應用程序進行了更多的合作之後，我想我會回來發佈我們迄今爲止的想法和經驗，希望它能幫助某人。

大廈@Peter Suwara的偉大後，我們到達了類似的策略最初

• 有一個根/父導航樹
• 對於樹中的每一個畫面，有QueryRenderer作爲根所有表象/啞組件包含
• 使用片段就像我們在下面他的回答的評論，雖然討論的子

內申報數據的依賴性，這種做法可能並不總是最好的。經過內部進一步討論，我們得出的結論是，有太多的情況下，這可能沒有什麼意義畢竟一對夫婦的原因：

• 如果您檢索每個屏幕加載數據，你時常會結束比往往更多的往返。您想要考慮應用程序流程，並獲取儘可能多的數據，這些數據是可用/需要的路線，而且是兒童。此外，如果您在同一個QueryRenderer中檢索屏幕的子組件的所有數據，則有時可能最終會獲取永不會顯示給用戶的數據（即，很少顯示的詳細信息視圖的詳細信息，或者類似的情況）。

一些更多的思考和討論後，我們來到了這個原則進行的拇指中繼樹時創建一個新的QueryRenderer「根」：

創建只要您一個新的QueryRenderer需要一個新的錯誤處理策略

這出於非常實際的原因，它是您必須處理錯誤/數據加載的唯一機會，但它也對我們來說在用戶流和構成方面是有意義的，因爲通常這兩件事發生了碰撞 - 當你到達一個新的「流」/你的一部分時，你需要一種處理網絡錯誤的新方法應用程序。也許Facebook上的一些更聰明的頭腦在我們面前想到了這一點？ :-)

就像所有的經驗法則一樣，它只是 - 一個指南，而不是一個規則，當然它也有例外。然而，對我們來說內部似乎是有意義的 - 至少現在是這樣。

任何和所有關於這些想法的反饋都是非常受歡迎的，因爲我認爲官方文檔至少沒有什麼可說的，因此我們只有在文檔和常規模式隨着時間得到解決之後才進行社區討論。

Answer 2

謝謝你帶了這個話題。我也剛剛進入ReactNative的Relay，並帶來了一些令人興奮的結果。

首先，我很驚訝將反映GraphQL數據庫的UI組件帶到屏幕是多麼容易。在學習JavaScript基礎知識和反應原生管道的初始開銷之後，Relay已經成爲展示數據的絕佳方式。

關於最佳實踐，我無法確定如何展示您的 QueryRenderer和fragmentContainer，但是我可以描述我們呈現數據的方式。

首先我們創建一個react-navigation堆棧和選項卡。在每個主屏幕中我們運行一個QueryRenderer。然後在那個QueryRenderer中，對於每個特定的UI組件，我們分成一個fragmentContainer。

• 導航流量（反應的導航，堆疊/標籤導航器）
• 屏幕（QueryRenderer）UI
• 空間/組分（fragmentContainer）

這使得我們可以創建所需的主查詢對於屏幕，然後分解組件數據以適應消耗組件，這些消耗組件很容易通過它們代表的GraphQL查詢片段來定義。然而，這意味着我們正在跨應用程序運行多個查詢，而沒有中央帳戶查詢將整個渲染整合到一個整潔的包中。

理想情況下，我想嘗試在導航器頂部的QueryRenderer，但是我還沒有完全弄清楚如何以及如果這將工作，因爲導航器不響應render（）函數，這是QueryRenderer是必需的。

我也有興趣聽到其他人如何在可導航的反應本機應用程序中應用中繼的方法。