QueryRenderer在Relay Modern中的作用？

Question

所以，首先是一些背景知識 。 我是一名原生的iOS / Android開發人員，現在正在開始我的第一個React Native項目。 它帶來了Javascript的所有好處和痛苦，但到目前為止我非常喜歡它:-)我還決定第一次嘗試使用GraphQL。

作為一般的React環境的新手，我也沒有任何關於Relay的先驗知識，但是在我的創業社區的朋友和我的web-dev同事的推薦下選擇了它。 我也被警告過一個有點陡峭的學習曲線，但無論如何我決定繼續 - 我已經在與JS和一個新的移動平台的0.xx版本進行一場艱苦的戰斗，所以到底是什么，對吧？ :-)我設法正確地設置了我的項目並用QueryRenderer了我的GQL服務器，這是一個很大的安慰:-)

所以，關於問題

我很難搞清楚容器/組件的關系，以及一般的容器組成。 閱讀關於作文的文檔有所幫助，但我對QueryRenderer的作用仍有疑問

• QueryRenderer被docs稱為每個Relay樹的根容器。 這是否意味着應該在我們的應用程序中為root創建一個QueryRenderer ？ 或者在每個導航路徑的根目錄（即我們的應用程序中的選項卡）？ 或者僅針對每個容器組件（與表示/啞/純組件相反，React明智）？ 請注意，我不是在尋找意見，而是尋求最佳實踐:-)
• FragmentContainer （或任何其他容器）可以在“父”組件中沒有QueryRenderer情況下工作嗎？
• QueryRenderer如何鏈接到子容器？ 它是否獲取子容器所需的所有數據的總和，然后從緩存中讀取子容器，或者？ 如果是這樣，我誤解了Relay的優點 - 我們認為每個組件都可以獨立於其他所有組件檢索數據，並且每個組件都不了解其他組件（包括父/子組件）的數據要求）。 我認為這個假設也讓我對QueryRenderer ，並且需要一個“Root”容器。
• 如果QueryRenderer是中繼樹的“父”/“根”中繼容器，那么它如何根據它的請求呈現視圖組件呢？ 為什么它必須有一個請求？ 何時以及我們應該使用QueryRenderer ？

任何幫助深表感謝 ：-）

Answer 1

感謝您提出這個話題。 我也剛剛使用ReactNative進入Relay，並獲得了一些令人興奮的結果。

首先，我很驚訝將用於反映GraphQL數據庫的UI組件帶到屏幕上是多么容易。 在學習了JavaScript和反應原生流水線的基礎知識的最初開銷之后，Relay已經成為一種呈現數據的絕佳方式。

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

首先，我們創建一個反應導航堆棧和選項卡。 在每個主屏幕內，我們運行QueryRenderer。 然后在該QueryRenderer中，對於每個特定的UI組件，我們分成一個fragmentContainer。

• 導航流程（反應導航，堆棧/標簽導航器）
• 屏幕（QueryRenderer）UI
• 小部件/組件（fragmentContainer）

這允許我們為屏幕創建所需的主要查詢，然后拆分組件數據以適應易於由其所代表的GraphQL查詢片段定義的可消耗組件。 但是，這確實意味着我們在應用程序中運行多個查詢而沒有中央帳戶查詢將整個呈現包裝成一個整潔的包。

理想情況下，我想在導航器的頂部嘗試一個QueryRenderer，但是我還沒有完全了解如何以及如果這可以工作，因為Navigators不響應render（）函數，這是QueryRenderer所在的位置需要。

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

Answer 2

因此，在使用我們的應用程序進行了更多工作之后，我想我會回來發布關於我們迄今為止的想法和經驗，希望它可以幫助某人。

在@Peter Suwara的偉大帖子的基礎上，我們最初達成了類似的策略

• 有一個根/父導航樹
• 對於樹中的每個屏幕，將QueryRenderer作為其包含的所有表示/啞元組件的根
• 使用片段在子組件中聲明數據依賴性

就像我們在下面的評論中討論他的答案一樣，這種方法可能並不總是最好的。 在內部進一步討論之后，我們得出的結論是，由於以下幾個原因，有太多案例可能沒有意義：

• 如果您為每個屏幕加載檢索數據，通常會有更多的往返次數。 您希望將app-flow考慮在內，並獲取盡可能多的數據，以及路由及其子項所需的數據。
• 此外，如果您在同一QueryRenderer上檢索屏幕的子組件的所有數據，您有時可能最終會獲取永遠不會向用戶顯示的數據（即很少顯示的詳細信息視圖的詳細信息或類似情況） 。

經過一番思考和討論后，我們想出了這個經驗法則，以便何時創建一個Relay樹的新QueryRenderer“root”：

無論何時需要新的錯誤處理策略，都要創建一個新的QueryRenderer

這是因為非常實際的原因，它是您處理數據錯誤/加載的唯一機會，但它對用戶流和組合的方式也有意義，因為通常兩個事情發生沖突 - 你想要一個新的當您到達應用程序的新“流程”/部分時處理網絡錯誤的方法。 也許Facebook的一些聰明人在我們面前想到了這一點？ :-)

與所有經驗法則一樣，它只是 - 指南，而不是規則，當然也有例外。 然而，它似乎對我們內部有意義 - 至少目前如此。

關於這些想法的任何和所有反饋都是非常受歡迎的，因為我認為官方文檔至少可以說是乏善可陳的，因此社區討論是我們所有的，直到文檔和一般模式隨着時間的推移而解決。