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