所以，首先一点背景。 我是一名原生的iOS / Android开发人员，现在正在开始我的第一个React Native项目。它带来了Javascript的所有好处和痛苦，但到目前为止我非常喜欢它:-)我还决定第一次尝试使用GraphQL。
对于React环境的新手，我也没有任何关于Relay的先验知识，但是在我的创业社区的朋友和我的web-dev同事的推荐下选择了它。我也被警告过一个有点陡峭的学习曲线，但无论如何我决定继续 - 我已经在与JS和一个新的移动平台的0.xx版本进行一场艰苦的战斗，所以到底是什么，对吧？ :-)我设法正确地设置了我的项目并用QueryRenderer整理到我的GQL服务器，这是一个很大的解脱： - ）
所以，关于问题
我很难搞清楚容器/组件的关系以及容器组成。阅读the docs on composition有帮助，但我对QueryRenderer
QueryRenderer是每个中继树的根容器。这是否意味着应该在我们的应用中为根提供QueryRenderer？或者在每个导航路径的根目录（即我们的应用程序中的标签）？或者仅针对每个容器组件（与表示/哑/纯组件相反，React明智）？请注意，我不是在寻找意见，而是寻求最佳实践的论据： - ）FragmentContainer（或其他任何容器）可以在“父”组件中没有QueryRenderer的情况下工作吗？QueryRenderer如何链接到子容器？它是否获取子容器所需的所有数据的总和，然后从缓存中读取子容器，或者？如果是这样，我误解了Relay的优点 - 我们认为每个组件都可以独立于其他所有组件检索数据，并且每个组件都不了解其他组件（包括父/子组件）的数据要求）。我认为这个假设也使我对QueryRenderer和“Root”容器的需求感到困惑。QueryRenderer是继电器树的“父”/“根”中继容器，那么基于它的请求如何呈现视图组件呢？为什么它必须有一个请求？何时以及我们应该使用QueryRenderer？非常感谢任何帮助： - ）
答案 0 :(得分：9)
感谢您提出这个话题。我也刚刚使用ReactNative进入Relay，并获得了一些令人兴奋的结果。
首先，我很惊讶将反映GraphQL数据库的UI组件带到屏幕上是多么容易。在学习了JavaScript和反应原生流水线的基础知识的最初开销之后，Relay已成为呈现数据的绝佳方式。
关于最佳实践，我无法确定如何展示您的 QueryRenderer和fragmentContainer，但我可以描述我们呈现数据的方式。
首先，我们创建一个反应导航堆栈和选项卡。在每个主屏幕内，我们运行QueryRenderer。然后在该QueryRenderer中，对于每个特定的UI组件，我们分成一个fragmentContainer。
这允许我们为屏幕创建所需的主查询，然后分解组件数据以适应易于由其所代表的GraphQL查询片段定义的可消耗组件。但是，这确实意味着我们在整个应用程序中运行多个查询而没有中央帐户查询将整个呈现包装成一个整洁的包。
理想情况下，我想尝试在导航器顶部的QueryRenderer，但是我还没有完全了解如何以及如果这将起作用，因为导航器不响应render（）函数，这是QueryRenderer是必需的。
我也有兴趣听听其他人如何在可导航的本地应用程序中应用中继的方法。
答案 1 :(得分：9)
因此，在使用我们的应用程序进行了更多工作之后，我想我会回来发布关于我们迄今为止的想法和经验，希望它可以帮助某人。
在@Peter Suwara的伟大帖子的基础上，我们最初达成了类似的策略
就像我们在下面的评论中讨论过他的答案一样，这种方法可能并不总是最好的。经过内部的进一步讨论后，我们得出的结论是，由于以下几个原因，有太多案例可能没有意义：
经过一番思考和讨论后，我们想出了什么时候创建Relay树的新QueryRenderer“root”这个经验法则：
为您需要新的错误处理策略时创建新的QueryRenderer
这是因为非常实际的原因，它是你必须处理数据错误/加载的唯一机会，但它对用户流和组合方式也有意义，因为通常这两件事发生冲突 - 你想要一种新的方式来处理网络错误，当你到达你的应用程序的新“流”/部分。也许Facebook的一些聪明人在我们面前想到了这一点？ ： - ）
与所有经验法则一样，它只是 - 指南，而不是规则，当然也有例外。然而，它似乎对我们内部有意义 - 至少目前如此。
对这些想法的任何和所有反馈都非常受欢迎，因为我认为官方文档至少可以说是乏善可陈，因此社区讨论是我们所有的，直到文档和一般模式随着时间的推移而解决。