“新的获取模式”不是把东西变成和GraphQL之前一样的吗?

c9x0cxw0  于 2022-10-01  发布在  其他
关注(0)|答案(1)|浏览(124)

在使用GraphQL时,我们的想法是使用单个请求针对整个页面询问您需要什么,并且只询问您需要什么。防止请求“竞争条件”(缺少更好的术语),单独的请求请求相同的数据,如用户名。

有了布局RFC和Reaction服务器组件,甚至钩子,理论上每个组件现在都应该负责获取自己的数据。

不要误解我的意思,DX方面,我更喜欢这种方式,而不是适当的钻取模式,即在/page中运行查询,然后将datadata.whatever向下传递给每个组件

但是,如果每个组件现在都在执行自己的请求,我们无论如何都会回到REST模式。每个组件执行自己的请求,并分别请求相同的数据,如用户名。

只是用了一种不同的方式。但这是一回事。我看到的唯一很大的区别是如果使用Apollo,那么Apollo缓存

zrfyljdw

zrfyljdw1#

但是,如果每个组件现在都在执行自己的请求,我们无论如何都会回到REST模式。

这并不是“REST”的一部分,这只是一个人可以做出的可能的设计决定。

在使用GraphQL时,我们的想法是使用单个请求针对整个页面询问您需要什么,并且只询问您需要什么。

提升GraphQL查询并请求更大的数据部分是一个设计决策,而不是GraphQL固有的。GraphQL文档中没有规定您必须在一次请求中完成整个页面的API需求。

这并不意味着GraphQL毫无用处。只有在组件需要的时候,GraphQL才会被用来精确地获取。GraphQLS的能力来自于确保你只在你的场景中得到你需要的东西,而不一定是“我一次得到整个页面上的所有东西”。同样,后者是一个设计决定。当然,GraphQL使它成为一种选项,但它不一定是已定义的做事方式。

事实上,有人可能会争辩说,组件级查询更好,因为您可以让请求数据的组件的本地加载状态,而不会阻塞整个页面。如果您仍然想要页面级别的加载状态,现在可以通过悬念轻松实现。

您可能还会争辩说,如果您使用客户端网络层缓存,执行范围更大的查询也会增加缓存命中率,因为缓存中提供所需的所有内容的可能性更高。
防止请求“竞争条件”(缺少更好的术语),单独的请求请求相同的数据,如用户名。

如果您有适当的网络缓存存储,则您仍然可以使用该属性进行组件级查询。或者构建您的应用程序,以便在组件树中更高的组件中获取这些数据,并通过上下文或其他方式向下传递。

相关问题