2017-05-18 73 views
11

所以,首先有点背景。 我是一位本机iOS/Android开发人员,现在开始我的第一个React Native项目。它带来了Javascript的所有好处和痛苦,但到目前为止,我非常喜欢它:-)我也决定也第一次尝试使用GraphQL。QueryRenderer在继电器现代中的角色?

作为React环境中的新手,我也没有任何关于Relay的知识,但是在我的创业社区的朋友和我的web-dev同事的推荐中选择了它。我也被告知学习曲线有些陡峭,但决定继续前进 - 我已经与JS和一个0.xx版本的新移动平台进行了艰苦的斗争,所以到底什么是对的? :-)我设法通过我的GQL服务器正确设置我的项目和冲压整体带QueryRenderer,这是一个极大的安慰:-)

因此,在对问题

我很难找出容器/组件的关系,以及容器的组成。阅读the docs on composition帮助,但我仍然怀疑过的QueryRenderer

  • QueryRenderer的角色由文档据说是每一个接力树的根容器。这是否意味着我们应用程序中的根应该有QueryRenderer?或者在每个导航路径的根目录下(即我们应用程序中的选项卡)?或者只是针对每个容器组件(与表示/哑/纯组件相反,React明智)?请注意,我不是在寻找意见,而是最佳实践的论点:-)
  • FragmentContainer(或其他任何容器,就此而言)在“父”组件中的作业没有QueryRenderer
  • QueryRenderer如何链接到子容器?它是否获取子容器所需的所有数据的总和,然后从高速缓存中读取子容器,或者?如果是这样,我误解了Relay的优点 - 我们觉得每个组件都可以独立于每个其他组件获取数据,并且每个组件都不知道其他组件的数据需求(包括父/子组件)。我认为这个假设也令我对QueryRenderer感到困惑,并且需要一个“根”容器。
  • 如果QueryRenderer是中继树的“父”/“根”中继容器,它如何根据请求呈现视图组件?为什么它必须有一个请求?什么时候应该使用QueryRenderer

任何帮助深表感谢:-)

回答

5

因此,在与我们的应用程序进行了更多的合作之后,我想我会回来发布我们迄今为止的想法和经验,希望它能帮助某人。

大厦@Peter Suwara的伟大后,我们到达了类似的策略最初

  • 有一个根/父导航树
  • 对于树中的每一个画面,有QueryRenderer作为根所有表象/哑组件包含
  • 使用片段就像我们在下面他的回答的评论,虽然讨论的子

内申报数据的依赖性,这种做法可能并不总是最好的。经过内部进一步讨论,我们得出的结论是,有太多的情况下,这可能没有什么意义毕竟一对夫妇的原因:

  • 如果您检索每个屏幕加载数据,你时常会结束比往往更多的往返。您想要考虑应用程序流程,并获取尽可能多的数据,这些数据是可用/需要的路线,而且是儿童。此外,如果您在同一个QueryRenderer中检索屏幕的子组件的所有数据,则有时可能最终会获取永不会显示给用户的数据(即,很少显示的详细信息视图的详细信息,或者类似的情况)。

一些更多的思考和讨论后,我们来到了这个原则进行的拇指中继树时创建一个新的QueryRenderer“根”:

创建只要您一个新的QueryRenderer需要一个新的错误处理策略

这出于非常实际的原因,它是您必须处理错误/数据加载的唯一机会,但它也对我们来说在用户流和构成方面是有意义的,因为通常这两件事发生了碰撞 - 当你到达一个新的“流”/你的一部分时,你需要一种处理网络错误的新方法应用程序。也许Facebook上的一些更聪明的头脑在我们面前想到了这一点? :-)

就像所有的经验法则一样,它只是 - 一个指南,而不是一个规则,当然它也有例外。然而,对我们来说内部似乎是有意义的 - 至少现在是这样。

任何和所有关于这些想法的反馈都是非常受欢迎的,因为我认为官方文档至少没有什么可说的,因此我们只有在文档和常规模式随着时间得到解决之后才进行社区讨论。

+0

如果有足够多的人满意答案,我将最终将其标记为“已接受”,以便将来访问此帖的任何人。我会等待,看看其他人是否同意我们的策略,但:-) – jhm

+0

是不是中继足够聪明,只有当组件呈现时才能获取片段的数据?例如,你可能有一个带有片段的根查询... User_friends;我相信只有当使用它的组件呈现时,Relay才会获取这些片段的数据。如果我错了,请纠正我 –

+1

回复我自己,我刚刚在父QueryRenderer中尝试过一个子fragmentContainer,实际上,QueryRenderer为子fragmentContainer提取数据,即使当孩子甚至还没有呈现时。无论如何,我将不得不提出两个答案,因为实际上取决于具体情况=) –

7

谢谢你带了这个话题。我也刚刚进入ReactNative的Relay,并带来了一些令人兴奋的结果。

首先,我很惊讶将反映GraphQL数据库的UI组件带到屏幕是多么容易。在学习JavaScript基础知识和反应原生管道的初始开销之后,Relay已经成为展示数据的绝佳方式。

关于最佳实践,我无法确定如何展示您的 QueryRenderer和fragmentContainer,但是我可以描述我们呈现数据的方式。

首先我们创建一个react-navigation堆栈和选项卡。在每个主屏幕中我们运行一个QueryRenderer。然后在那个QueryRenderer中,对于每个特定的UI组件,我们分成一个fragmentContainer。

  • 导航流量(反应的导航,堆叠/标签导航器)
  • 屏幕(QueryRenderer)UI
  • 空间/组分(fragmentContainer)

这使得我们可以创建所需的主查询对于屏幕,然后分解组件数据以适应消耗组件,这些消耗组件很容易通过它们代表的GraphQL查询片段来定义。然而,这意味着我们正在跨应用程序运行多个查询,而没有中央帐户查询将整个渲染整合到一个整洁的包中。

理想情况下,我想尝试在导航器顶部的QueryRenderer,但是我还没有完全弄清楚如何以及如果这将工作,因为导航器不响应render()函数,这是QueryRenderer是必需的。

我也有兴趣听到其他人如何在可导航的反应本机应用程序中应用中继的方法。

+0

嘿,彼得,感谢您花时间写出如此详细的答案:-)经过一番讨论后,这与我们到达的策略完全相同,并且当我看到您的帖子时想要尝试它 - 因此可能既不是我们离得很远;-)不幸的是,当我试图实现它时遇到了另一个问题,并在https://github.com/facebook/relay/issues/1665上发布了它(jhalborg)。一旦我得到它的工作,我会回到这里总结我的经验 – jhm

+0

然而,如果这是最好的方法,如果你有一个栈导航中的深导航树作为其中一个选项卡的孩子 - 在这种情况下,queryrenderer会在堆栈导航树中更深入地访问屏幕之前获取大量与用户无关的数据,因此将第二个QueryRenderer作为新的“根” “进一步在堆栈导航树下 - 你怎么看? – jhm

+1

很高兴听到我们在同一页面上。感谢您的信息。关于多余的数据。我们正在看这个。目前,我们不需要的任何东西都会从查询中删除。实际上,我遇到了一个有关元数据的有趣问题。 UI不反映查询的结果,但是使用道具传递。细节非常复杂,所以在这里不会涉及它。但到目前为止,我们的解决方案似乎符合我们的要求即使有一些异常情况,产生结果的速度肯定比Native快得多。 –