#1914 Use default values for fields of input types when default argument value is provided#2085
Conversation
| buildValue(of.getValue(), objectType.getField(of.getName()).getType()))); | ||
| objectType.getFieldDefinitions().forEach( | ||
| f -> { | ||
| final Value<?> fieldValueFromDefaultObjectValue = defaultValue.getObjectFields().stream() |
There was a problem hiding this comment.
Performance of this statement can be improved by keeping a map of Object field's name and the field itself in ObjectValue class.
There was a problem hiding this comment.
fields of objects are typically < 10 say - iterating them is not a real problem. Also schema building is KN OWN to be a heavy thing they can be slower (where slower is not really slow) - So there are no perf savings to be had in schema generation as a rule
That is not to say it should be terrible - but that when people come to us about performance its NOT in the schema gen side of things
|
|
||
| type Query { | ||
| outputField(inputArg: InputType = {age : 666, name : "nameViaArg"}, inputBoolean: Boolean = true, inputInt: Int = 1, inputString: String = "viaArgString"): OutputType | ||
| outputField(inputArg: InputType = {age : 666, complex : {boolean : true, int : 666, string : "string"}, name : "nameViaArg", rocks : true}, inputBoolean: Boolean = true, inputInt: Int = 1, inputString: String = "viaArgString"): OutputType |
There was a problem hiding this comment.
Introspection of schema now considers the default values defined in Input types.
|
Given: what's the value? I expect I havent look in the code yet or the tests but can you answer this please either way |
|
I, too, expect null value, @bbakerman Let me add a test for this use case as well. |
| buildValue(of.getValue(), objectType.getField(of.getName()).getType()))); | ||
| objectType.getFieldDefinitions().forEach( | ||
| f -> { | ||
| final Value<?> fieldValueFromDefaultObjectValue = defaultValue.getObjectFields().stream() |
There was a problem hiding this comment.
fields of objects are typically < 10 say - iterating them is not a real problem. Also schema building is KN OWN to be a heavy thing they can be slower (where slower is not really slow) - So there are no perf savings to be had in schema generation as a rule
That is not to say it should be terrible - but that when people come to us about performance its NOT in the schema gen side of things
| map.put(f.getName(), fieldValueFromDefaultObjectValue != null ? buildValue(fieldValueFromDefaultObjectValue, f.getType()): f.getDefaultValue()); | ||
| } | ||
| ); | ||
| return map; |
There was a problem hiding this comment.
final Value<?> fieldValueFromDefaultObjectValue = defaultValue.getObjectFields().stream().filter(dvf -> dvf.getName().equals(f.getName())).map(ObjectField::getValue).findFirst().orElse(null);
ends up really hard to read. I like to put in simple methods to represent this
final Value<?> fieldValueFromDefaultObjectValue = buildFieldDefaultValue(defaultValue,...)
There was a problem hiding this comment.
@bbakerman Done. Refactored the long statement into a method.
|
|
||
| then: | ||
| result.errors.isEmpty() | ||
| result.data == [sayHello: "F1ValOverride & F2V"] |
There was a problem hiding this comment.
Can we get another test in place for when the inner field is named BUT the value is null
There was a problem hiding this comment.
do you something like
"default values in input objects are overridden when null value is provided in input"?
or do you mean the default value provided for a field in input type is null?
There was a problem hiding this comment.
@bbakerman Added a test where one of the fields in input type have null value (below this test)
Adds support for honoring the default values declared in input type definition (Issue)
Example 1
Schema:
Query:
arg value before change:
{}arg value after change:
{foo: "Bar"}Example 2
Schema:
Query:
arg value before change:
{field1: "F1ValOverride"}arg value after change:
{field1: "F1ValOverride", field2: "F2V"}