Apollo Client 中非规范化对象合并问题解析

问题背景

在使用 Apollo Client 进行 GraphQL 查询时，开发者可能会遇到重复网络请求的问题。这通常是由于缓存机制无法正确处理非规范化对象的合并导致的。本文将通过一个典型案例，深入分析问题原因并提供解决方案。

典型案例分析

在一个 React 应用中，开发者同时使用了两个 useQuery 钩子，分别查询 roadster 对象的不同字段：

1. 第一个查询请求 roadster 对象的 details 字段
2. 第二个查询请求 roadster 对象的 name 字段

这种情况下，开发者观察到四个网络请求被触发，其中第二个查询被重复执行。这种现象并非 Apollo Client 的缺陷，而是缓存合并策略导致的预期行为。

问题根源

Apollo Client 的缓存系统(InMemoryCache)对于非规范化对象的处理有以下特点：

1. 默认情况下，缓存系统会完全替换非规范化对象
2. 当两个查询返回相同类型的对象但包含不同字段时，后完成的查询会覆盖前一个查询的结果
3. 这种覆盖行为会导致前一个查询认为其数据已丢失，从而触发重新获取

解决方案

针对这类问题，开发者有以下几种解决方案：

方案一：添加唯一标识符

最理想的解决方案是确保所有对象都包含唯一标识符字段 id。这样缓存系统可以正确识别和合并相同实体的不同查询结果。

方案二：自定义合并函数

对于无法添加 id 的情况，可以为特定类型定义自定义合并策略：

new InMemoryCache({
  typePolicies: {
    Roadster: {
      merge: true, // 启用默认合并策略
    },
  },
})

这种配置会使缓存系统合并相同类型对象的字段，而不是完全替换。在上面的例子中，合并后的 Roadster 对象将同时包含 name 和 details 字段。

方案三：字段级合并策略

对于更复杂的情况，可以实现细粒度的合并函数：

new InMemoryCache({
  typePolicies: {
    Roadster: {
      fields: {
        details: {
          merge(existing, incoming) {
            return incoming || existing;
          }
        }
      }
    },
  },
})

最佳实践建议

1. 始终检查 Apollo Client 的控制台警告信息，这些警告通常会明确指出缓存合并问题
2. 在设计 GraphQL 类型时，尽可能包含唯一标识符字段
3. 对于无法修改的远程模式，提前规划好类型合并策略
4. 在开发阶段密切关注网络请求数量，异常重复请求往往是缓存问题的信号

总结

Apollo Client 的缓存机制为应用性能带来了显著提升，但需要开发者理解其工作原理。通过合理配置类型合并策略，可以有效避免重复请求问题，同时确保数据一致性。对于非规范化对象，特别需要注意合并行为的配置，这是优化 Apollo Client 使用体验的关键环节。