在使用GraphQL时,我们的想法是使用单个请求针对整个页面询问您需要什么,并且只询问您需要什么。防止请求“竞争条件”(缺少更好的术语),单独的请求请求相同的数据,如用户名。
有了布局RFC和Reaction服务器组件,甚至钩子,理论上每个组件现在都应该负责获取自己的数据。
不要误解我的意思,DX方面,我更喜欢这种方式,而不是适当的钻取模式,即在/page
中运行查询,然后将data
或data.whatever
向下传递给每个组件
但是,如果每个组件现在都在执行自己的请求,我们无论如何都会回到REST模式。每个组件执行自己的请求,并分别请求相同的数据,如用户名。
只是用了一种不同的方式。但这是一回事。我看到的唯一很大的区别是如果使用Apollo,那么Apollo缓存
1条答案
按热度按时间zrfyljdw1#
但是,如果每个组件现在都在执行自己的请求,我们无论如何都会回到REST模式。
这并不是“REST”的一部分,这只是一个人可以做出的可能的设计决定。
在使用GraphQL时,我们的想法是使用单个请求针对整个页面询问您需要什么,并且只询问您需要什么。
提升GraphQL查询并请求更大的数据部分是一个设计决策,而不是GraphQL固有的。GraphQL文档中没有规定您必须在一次请求中完成整个页面的API需求。
这并不意味着GraphQL毫无用处。只有在组件需要的时候,GraphQL才会被用来精确地获取。GraphQLS的能力来自于确保你只在你的场景中得到你需要的东西,而不一定是“我一次得到整个页面上的所有东西”。同样,后者是一个设计决定。当然,GraphQL使它成为一种选项,但它不一定是已定义的做事方式。
事实上,有人可能会争辩说,组件级查询更好,因为您可以让请求数据的组件的本地加载状态,而不会阻塞整个页面。如果您仍然想要页面级别的加载状态,现在可以通过悬念轻松实现。
您可能还会争辩说,如果您使用客户端网络层缓存,执行范围更大的查询也会增加缓存命中率,因为缓存中提供所需的所有内容的可能性更高。
防止请求“竞争条件”(缺少更好的术语),单独的请求请求相同的数据,如用户名。
如果您有适当的网络缓存存储,则您仍然可以使用该属性进行组件级查询。或者构建您的应用程序,以便在组件树中更高的组件中获取这些数据,并通过上下文或其他方式向下传递。