GraphQL-Ruby 2.3.1版本中可选参数行为的变更分析

在GraphQL-Ruby 2.3.1版本中，我们发现了一个关于输入对象参数处理的重要行为变更。这个变更影响了可选参数在请求中的表现方式，值得开发者特别注意。

行为变更详情

在2.3.0及更早版本中，GraphQL-Ruby处理输入对象时会包含所有定义的参数，即使这些参数在请求中没有提供值。例如，对于以下输入对象定义：

class SomeInput < Types::BaseInputObject
  argument :a, String, required: true
  argument :b, String, required: false
end

当客户端请求中不包含参数b时，2.3.0版本会生成如下哈希：

{
  :a => "xyz",
  :b => nil
}

而在2.3.1版本中，同样的请求会生成：

{
  :a => "xyz"
}

技术背景分析

这个变更实际上修正了一个长期存在的行为偏差。根据GraphQL规范，当参数既没有在请求中提供，也没有默认值时，它不应该出现在最终的参数哈希中。2.3.0及之前版本的行为（总是包含所有参数）实际上是不符合规范的。

这种变更特别影响了那些依赖参数总是存在的代码逻辑，比如使用DryStruct等工具自动转换哈希的情况。这些工具通常会期望所有定义的属性都存在。

解决方案

对于需要保持旧行为的应用，可以通过显式设置默认值来实现：

class SomeInput < Types::BaseInputObject
  argument :a, String, required: true
  argument :b, String, required: false, default_value: nil
end

这样设置后，即使客户端不提供b参数，它也会以nil值出现在参数哈希中。

后续版本更新

在2.3.2版本中，修复了另一个相关的问题——关于数组类型输入参数的处理。这个修复可能也解决了部分用户遇到的类似问题，特别是当使用输入对象列表时。

最佳实践建议

1. 显式处理可选参数：不要假设可选参数一定会出现在参数哈希中，应该总是检查参数是否存在。

2. 考虑使用默认值：如果业务逻辑需要参数总是存在，考虑设置适当的默认值。

3. 更新测试用例：确保测试覆盖参数缺失的情况，验证应用在各种场景下的行为。

4. 关注版本变更：定期检查GraphQL-Ruby的更新日志，特别是关于参数处理的变更。

这个变更虽然可能破坏现有代码，但它使GraphQL-Ruby更符合规范，长期来看有利于项目的维护和一致性。开发者应该根据自身情况选择适当的迁移策略。