QueryRenderer 在 Relay Modern 中的作用？
Role of QueryRenderer in Relay Modern?
那么，首先 介绍一些背景知识 。
我是一名本地 iOS/Android 开发人员，现在开始我的第一个 React Native 项目。它具有 Javascript 的所有优点和缺点，但到目前为止我非常喜欢它 :-) 我决定也第一次尝试 GraphQL。
作为 React 环境的新手，我也没有任何关于 Relay 的先验知识，但在我的创业社区和我的网络开发同事的推荐下选择了它。我还被警告学习曲线有点陡峭，但无论如何还是决定继续 - 我已经在与 JS 和新移动平台的 0.xx 版本进行艰苦的战斗，所以管它呢，对吧？ :-) 我设法正确设置了我的项目，并使用 QueryRenderer 将整个项目打通到我的 GQL 服务器，这让我松了一口气 :-)
所以，进入问题
我很难搞清楚 container/component 关系和一般的容器组成。阅读 the docs on composition 有所帮助，但我仍然怀疑 QueryRenderer
的作用
文档说 QueryRenderer 是每个中继树的根容器。这是否意味着我们的应用程序中应该有一个 QueryRenderer 作为根目录？或者在每个导航路径的根部（即我们应用程序中的选项卡）？或者只是针对每个容器组件（而不是 presentational/dumb/pure 组件，React 明智）？请注意，我不是在寻找意见，而是在寻找最佳实践的论据:-)FragmentContainer（或任何其他容器，就此而言）可以在“父”组件中没有 QueryRenderer 的情况下工作吗？QueryRenderer 如何链接到子容器？它是获取子容器想要的所有数据的总和，然后子容器从缓存中读取，还是？如果是这样，我误解了 Relay 的优点 - 我们的印象是每个组件都可以独立于其他组件检索数据，并且每个组件对其他组件的数据要求一无所知（包括 parent/child 组件）。我认为这个假设也是让我对 QueryRenderer 以及对“根”容器的需求感到困惑的原因。- 如果
QueryRenderer是中继树的“父”/“根”中继容器，为什么它必须根据它的请求渲染视图组件？为什么它必须有一个请求？我们应该在何时何地使用 QueryRenderer?
非常感谢任何帮助:-)
感谢您提出这个话题。我也刚刚开始使用 ReactNative 进行中继，并取得了一些令人兴奋的结果。
首先，我很惊讶将反映 GraphQL 数据库的 UI 组件带到屏幕上是多么容易。在学习 JavaScript 基础知识和 react-native 管道的初始开销之后，Relay 已成为呈现数据的绝佳方式。
关于最佳实践，我无法确定如何展示您的
QueryRenderer 和 fragmentContainer，但是我可以描述我们呈现数据的方式。
首先我们创建一个反应导航堆栈和选项卡。在每个主要屏幕中，我们 运行 一个 QueryRenderer。然后在该 QueryRenderer 中，对于每个特定的 UI 组件，我们分成一个 fragmentContainer。
- 导航流程（反应导航，Stack/Tab 导航器）
- 屏幕（QueryRenderer）UI
- Widget/Component（片段容器）
这使我们能够为屏幕创建所需的主要查询，然后分解组件数据以适应可使用的组件，这些组件很容易由它们表示的 GraphQL 查询片段定义。然而，这确实意味着我们 运行 在应用程序中进行多个查询，而无需中央帐户查询来将整个渲染打包成一个整洁的包。
理想情况下，我想在 Navigator 的顶部尝试一个 QueryRenderer，但是我还没有完全弄清楚这将如何工作以及是否可以工作，因为 Navigators 不响应 render() 函数，它是需要 QueryRenderer 的地方。
我也有兴趣听听其他人如何在可导航的 react-native 应用程序中应用中继。
因此，在使用我们的应用程序进行了更多工作之后，我想我会回到 post 来谈谈我们迄今为止的想法和经历，希望它能对某人有所帮助。
基于@Peter Suwara 的伟大 post，我们最初达成了类似的策略
- 有一个 root/parent 导航树
- 对于树中的每个屏幕，都有一个 QueryRenderer 作为其包含的所有 presentational/dumb 组件的根
- 使用片段声明子组件内的数据依赖关系
正如我们在他的回答下方的评论中所讨论的那样，这种方法可能并不总是最好的。经过内部进一步讨论后，我们得出的结论是，由于以下几个原因，在太多情况下这可能根本没有意义：
- 如果您为每次屏幕加载检索数据，您经常会遇到不必要的往返次数。您想要考虑应用程序流程，并为一条路线及其子路线获取与 viable/needed 一样多的数据。
- 此外，如果您在同一个 QueryRenderer 上检索屏幕子组件的所有数据，有时您可能最终会获取永远不会向用户显示的数据（即很少显示的详细信息视图的详细信息） ，或类似情况）。
经过更多的思考和讨论，我们得出了何时创建中继树的新 QueryRenderer 'root' 的经验法则：
每当您需要新的错误处理策略时创建一个新的 QueryRenderer
这是出于非常实际的原因，这是您必须处理 errors/loading 数据的唯一机会，但它在用户流和组合方面对我们来说也很有意义，通常这两个事情发生冲突 - 当您到达应用程序的新 'flow'/ 部分时，您需要一种新的方式来处理网络错误。也许 Facebook 的一些更聪明的负责人比我们先想到了这个？ :-)
与所有经验法则一样，它只是一个指南，而不是规则，当然也有例外。然而，这对我们内部来说似乎是有意义的——至少现在是这样。
非常欢迎对这些想法的任何和所有反馈，因为我认为官方文档至少可以说是乏善可陈，因此在文档和一般模式随着时间的推移得到解决之前，我们只有社区讨论。
那么，首先 介绍一些背景知识 。 我是一名本地 iOS/Android 开发人员，现在开始我的第一个 React Native 项目。它具有 Javascript 的所有优点和缺点，但到目前为止我非常喜欢它 :-) 我决定也第一次尝试 GraphQL。
作为 React 环境的新手，我也没有任何关于 Relay 的先验知识，但在我的创业社区和我的网络开发同事的推荐下选择了它。我还被警告学习曲线有点陡峭，但无论如何还是决定继续 - 我已经在与 JS 和新移动平台的 0.xx 版本进行艰苦的战斗，所以管它呢，对吧？ :-) 我设法正确设置了我的项目，并使用 QueryRenderer 将整个项目打通到我的 GQL 服务器，这让我松了一口气 :-)
所以，进入问题
我很难搞清楚 container/component 关系和一般的容器组成。阅读 the docs on composition 有所帮助，但我仍然怀疑 QueryRenderer
-
文档说
QueryRenderer是每个中继树的根容器。这是否意味着我们的应用程序中应该有一个QueryRenderer作为根目录？或者在每个导航路径的根部（即我们应用程序中的选项卡）？或者只是针对每个容器组件（而不是 presentational/dumb/pure 组件，React 明智）？请注意，我不是在寻找意见，而是在寻找最佳实践的论据:-)FragmentContainer（或任何其他容器，就此而言）可以在“父”组件中没有QueryRenderer的情况下工作吗？QueryRenderer如何链接到子容器？它是获取子容器想要的所有数据的总和，然后子容器从缓存中读取，还是？如果是这样，我误解了 Relay 的优点 - 我们的印象是每个组件都可以独立于其他组件检索数据，并且每个组件对其他组件的数据要求一无所知（包括 parent/child 组件）。我认为这个假设也是让我对QueryRenderer以及对“根”容器的需求感到困惑的原因。- 如果
QueryRenderer是中继树的“父”/“根”中继容器，为什么它必须根据它的请求渲染视图组件？为什么它必须有一个请求？我们应该在何时何地使用QueryRenderer?
非常感谢任何帮助:-)
感谢您提出这个话题。我也刚刚开始使用 ReactNative 进行中继，并取得了一些令人兴奋的结果。
首先，我很惊讶将反映 GraphQL 数据库的 UI 组件带到屏幕上是多么容易。在学习 JavaScript 基础知识和 react-native 管道的初始开销之后，Relay 已成为呈现数据的绝佳方式。
关于最佳实践，我无法确定如何展示您的 QueryRenderer 和 fragmentContainer，但是我可以描述我们呈现数据的方式。
首先我们创建一个反应导航堆栈和选项卡。在每个主要屏幕中，我们 运行 一个 QueryRenderer。然后在该 QueryRenderer 中，对于每个特定的 UI 组件，我们分成一个 fragmentContainer。
- 导航流程（反应导航，Stack/Tab 导航器）
- 屏幕（QueryRenderer）UI
- Widget/Component（片段容器）
这使我们能够为屏幕创建所需的主要查询，然后分解组件数据以适应可使用的组件，这些组件很容易由它们表示的 GraphQL 查询片段定义。然而，这确实意味着我们 运行 在应用程序中进行多个查询，而无需中央帐户查询来将整个渲染打包成一个整洁的包。
理想情况下，我想在 Navigator 的顶部尝试一个 QueryRenderer，但是我还没有完全弄清楚这将如何工作以及是否可以工作，因为 Navigators 不响应 render() 函数，它是需要 QueryRenderer 的地方。
我也有兴趣听听其他人如何在可导航的 react-native 应用程序中应用中继。
因此，在使用我们的应用程序进行了更多工作之后，我想我会回到 post 来谈谈我们迄今为止的想法和经历，希望它能对某人有所帮助。
基于@Peter Suwara 的伟大 post，我们最初达成了类似的策略
- 有一个 root/parent 导航树
- 对于树中的每个屏幕，都有一个 QueryRenderer 作为其包含的所有 presentational/dumb 组件的根
- 使用片段声明子组件内的数据依赖关系
正如我们在他的回答下方的评论中所讨论的那样，这种方法可能并不总是最好的。经过内部进一步讨论后，我们得出的结论是，由于以下几个原因，在太多情况下这可能根本没有意义：
- 如果您为每次屏幕加载检索数据，您经常会遇到不必要的往返次数。您想要考虑应用程序流程，并为一条路线及其子路线获取与 viable/needed 一样多的数据。
- 此外，如果您在同一个 QueryRenderer 上检索屏幕子组件的所有数据，有时您可能最终会获取永远不会向用户显示的数据（即很少显示的详细信息视图的详细信息） ，或类似情况）。
经过更多的思考和讨论，我们得出了何时创建中继树的新 QueryRenderer 'root' 的经验法则：
每当您需要新的错误处理策略时创建一个新的 QueryRenderer
这是出于非常实际的原因，这是您必须处理 errors/loading 数据的唯一机会，但它在用户流和组合方面对我们来说也很有意义，通常这两个事情发生冲突 - 当您到达应用程序的新 'flow'/ 部分时，您需要一种新的方式来处理网络错误。也许 Facebook 的一些更聪明的负责人比我们先想到了这个？ :-)
与所有经验法则一样，它只是一个指南，而不是规则，当然也有例外。然而，这对我们内部来说似乎是有意义的——至少现在是这样。
非常欢迎对这些想法的任何和所有反馈，因为我认为官方文档至少可以说是乏善可陈，因此在文档和一般模式随着时间的推移得到解决之前，我们只有社区讨论。