This is probably a long shot, but is it possible to conditionally require an argument based on either some logic, or based on the value of another argument? I have an Invoice model with a number of arguments, and nested in those arguments is the lineItems array. These arguments have been defined with an input object:
class CreateInvoiceMutation < Types::BaseMutation
...
argument :line_items, [Types::Inputs::LineItemAttributes], required: true
...
end
class Types::Inputs::LineItemAttributes < Types::BaseInputObject
argument :field_a, Integer, required: false
argument :field_b, String, required: false
argument :field_c, Float, required: false
end
On the client side, empty line items are generated, so when the form is submit it's possible that the lineItems argument will contain empty line items. As such, I can't simply set all of the arguments to be required: true as it would immediately fail.
What I need is for the argument to be required if the field_a argument is present, so something like this would be perfect:
class Types::Inputs::LineItemAttributes < Types::BaseInputObject
argument :field_a, Integer, required: false
argument :field_b, String, required: proc { |attr| attr.field_a.present? }
argument :field_c, Float, required: proc { |attr| attr.field_a.present? }
end
Obviously there's probably a nice way of handling this than a proc but this just shows the kind of thing I'm after.
This may already be possible but I haven't seen it documented anywhere.
This isn't possible in GraphQL _proper_, because an argument's type must be either T (optional) or T! (required).
However, someday we could have dynamic support in this library. For example, the argument's type is optional, but we add some kind of error if a dynamic constraint isn't met.
It would be useful. Another use case would be a create and update mutation that share arguments. In the update mutation some properties shouldn't be updatable so would not be required but they would on create.
Obviously this can all be handled via validations in the underlying models so it's not a major issue but it would be useful having the API reject things before it got that far
I don't have plans to work on this soon, so I'll close out the issue. If someone wants to propose or discuss specific constraints or validations, feel free to open another issue or PR!
Most helpful comment
It would be useful. Another use case would be a
createandupdatemutation that share arguments. In theupdatemutation some properties shouldn't be updatable so would not be required but they would oncreate.Obviously this can all be handled via validations in the underlying models so it's not a major issue but it would be useful having the API reject things before it got that far