Support for Optional argument handling

[PhilippS93]

First of all, thank you for the library, it's very great! 👏

Is your feature request related to a problem? Please describe.
GraphQL supports 3 states of input arguments.

• They can be set but null
• They can be not set
• They can be set and not null

Java only represents two states, set or not set. But the information if the property was present in the request is missing.
GraphQL Frameworks for java like graphql-java-kickstart/graphql-java-tools#404 support this feature by using Optional<>-java class.

Describe the solution you'd like
Add a toggle in the generation to generate Optional<> fields in input-classes.

e.g. for

input EditUserInput {
    id: ID!
    name: String!
    address: String
}

it currently generates:

public class EditUserInputDTO implements java.io.Serializable {

    @javax.validation.constraints.NotNull
    private String id;
    @javax.validation.constraints.NotNull
    private String name;
    private String address;
  //...
}

but now, we could generate:

public class EditUserInput DTO implements java.io.Serializable {

    @javax.validation.constraints.NotNull
    private String id;
    @javax.validation.constraints.NotNull
    private String name;
    private Optional<String> address;
  //...
}

This would allow us to check if the property should be deleted (Optional.empty() == false but null) or was just not set by the frontend (Optional.empty() == true) and must not be considered for updating or deletion.

Describe alternatives you've considered
None

[kobylynskyi]

Java 8's Optional was mainly intended for return values from methods, and not for properties of Java classes, as described in Optional in Java SE 8:

Of course, people will do what they want. But we did have a clear intention when adding this feature, and it was not to be a general purpose Maybe or Some type, as much as many people would have liked us to do so. Our intention was to provide a limited mechanism for library method return types where there needed to be a clear way to represent "no result", and using null for such was overwhelmingly likely to cause errors.

The key here is the focus on use as a return type. The class is definitively not intended for use as a property of a Java Bean. Witness to this is that Optional does not implement Serializable, which is generally necessary for widespread use as a property of an object.

So I am parking this feature request for now.

[PhilippS93]

Thanks for your response.
Because graphql-java-tools already support this feature, how could we solve this by using the codegen lib?

[MartyWind]

@kobylynskyi I think this feature still is relevant. I need something like that too. My workaround is to pass the arguments Map<String, Any> into each method call, but something like Optional would be much nicer.
It would also enable the use of the convenience methods that Optional provides.

[rwo-trackunit]

Sorry for reawakening and old one, but I needed this too, and tried to see what it would take.
This is a POC for supporting Optional<?> on all input objects:
rwo-trackunit#1

The solution "abuses" Optional as described, where it will be either null, .isEmpty() == true or .get() would have a value. It is tested on Java, but still needs work, as it is a POC.

Example:

input BoundingBoxInput {
    nw: CoordinatesInput!
    se: CoordinatesInput!
    zoom: Float
}

becomes

public class BoundingBoxInput implements java.io.Serializable {
    private CoordinatesInput nw;
    private CoordinatesInput se;
    private java.util.Optional<Double> zoom;
    
    ...

Let me know if such an approach would be acceptable, despite not adhering to the intention of Optional.