限制

Relay Resolvers 确实有一些限制。在这里，我们将收集已知限制的列表，并在可能的情况下提供替代方案。

没有 info 参数

在完整的 GraphQL 实现中，解析器将可以访问 info 参数。此参数目前在 Relay Resolvers 中不可用。

不支持抽象类型

目前，无法使用 Relay Resolvers 定义具有多个具体类型的接口或联合。这是我们将来希望支持的功能，但尚未实现。

所有字段都必须是可空类型

目前，所有解析器必须被类型化为可空类型，以便支持将错误强制转换为 null，而无需实现 null 冒泡。将来，我们计划让 Resolvers 支持某种版本的 严格语义可空性。

并非所有 GraphQL 结构都受支持

目前，Relay Resolvers 只支持 GraphQL 结构的一个子集。例如，目前无法使用 Relay Resolvers 定义输入类型、枚举或接口。

不支持突变

目前，Relay Resolvers 只支持读取路径。定义突变字段尚未支持。我们正在努力了解对响应式模式执行突变的意义，并希望将来支持它们。

解析器始终按需评估

目前，Relay Resolvers 始终按需评估，以每个片段为基础。这样做的好处是，如果解析器未被读取，它将永远不会被评估。但是，如果您的客户端模式最终对获取数据发出异步请求，因为它被读取，这会导致瀑布问题。我们正在积极探索 Relay Resolvers 的其他执行策略，例如在请求时评估查询中的所有字段，但预计解析器的定义方式将保持稳定。

冗长/笨拙的 docblock 语法

目前，定义解析器需要定义一个带有 docblock 的函数，该函数使用特殊语法并重复函数名称和类型中已指定的 information。此外，为了强制这些值匹配，Relay 在其生成的类型中发出类型断言。虽然这些断言确实确保了安全性，但它们是一种笨拙的开发体验。

为了解决这些问题，我们正在探索一种更简化的 approach，其中名称和类型可以从您的 Flow 或 TypeScript 代码中推断出来，类似于 Grats 采用的 approach。此语法可能在 Relay 的未来版本中可用。