Apollo Client 中如何为 REST API 数据添加 __typename 支持

背景介绍

在 GraphQL 生态系统中，Apollo Client 是一个广泛使用的状态管理库，它不仅可以处理 GraphQL 数据，有时也需要与传统的 REST API 进行交互。一个常见的挑战是当我们需要将 REST API 返回的数据传递给原本设计用于处理 GraphQL 响应的 React 组件时，会遇到类型系统不匹配的问题。

核心问题

GraphQL 响应中会自动包含 __typename 字段，这是 Apollo Client 用来标识数据类型的元信息。当组件逻辑依赖于这些类型信息时（特别是在处理联合类型或接口实现时），直接从 REST API 获取的 JSON 数据由于缺少这些字段会导致组件无法正常工作。

技术细节分析

Apollo Client 的类型系统机制

Apollo Client 在发送 GraphQL 查询时会自动添加 __typename 字段到请求中，服务器响应时会返回这些类型信息。客户端缓存利用这些信息来构建规范化数据存储。

联合类型的特殊处理

对于 GraphQL 中的联合类型（如示例中的 SupportingMessages），组件通常会通过 __typename 来区分不同的可能类型：

union SupportingMessages =
  | DSPlainText
  | DSGraphicText
  | DSStandardBadge

对应的 React 组件可能会使用 switch 语句基于 __typename 来渲染不同的 UI。

解决方案探讨

直接修改 REST 响应数据

最直接的解决方案是确保 REST API 返回的数据中包含必要的 __typename 字段。这需要后端服务的配合，或者在数据到达前端前进行预处理。

客户端数据转换

如果无法修改后端，可以在前端对数据进行转换：

const enhancedData = {
  productRatingSummary: {
    __typename: 'ProductRatingSummary',
    sectionHeadingAccessibilityText: "Reviews",
    summary: {
      __typename: 'RatingSummary',
      primary: "9.0",
      secondary: "Wonderful",
      theme: "positive"
    },
    info: null,
  }
}

Apollo Cache 的局限性

尝试通过 Apollo Client 缓存自动添加 __typename 是不可行的，因为：

1. 客户端不知道服务端的类型系统结构
2. 对于联合类型，客户端无法确定具体应该使用哪个 __typename

最佳实践建议

1. 统一数据格式：尽可能让 REST API 返回与 GraphQL 相同结构的数据，包括 __typename

2. 创建数据适配层：在前端实现一个转换层，专门负责将 REST 数据转换为 GraphQL 兼容格式

3. 组件解耦：考虑将依赖 __typename 的逻辑提取到更高层，使展示组件不直接依赖类型信息

4. 类型安全：使用 TypeScript 类型守卫来确保运行时类型安全，而不仅仅依赖 __typename

总结

在混合使用 GraphQL 和 REST API 的现代前端应用中，数据类型的一致性至关重要。虽然 Apollo Client 提供了强大的缓存和状态管理能力，但它无法自动弥补 REST API 数据中缺失的 GraphQL 特定元信息。开发者需要根据具体情况选择最适合的数据转换策略，确保组件能够正确消费来自不同来源的数据。