Allow the user to change InputObjectType's default value on non-specified inputs to a sentinel value #1506
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR aims to remove the ambiguity that happens with
InputObjectType
s when accessing optional fields using theinput.<attribute>
"dot access" syntax.Current behavior:
If an optional input field is defined but has not been specified in an incoming
InputObjectType
, it comes back as aNone
This is ambiguous, since the user could also have set that specific field to
None
, meaning we wouldn't be able to tell between an explicit setting toNone
versus the field not being set at all.Proposed behavior in this PR:
Introduce a non-breaking, opt-in method to allow the users to change this default value getter behavior in InputObjectTypes to any value that they want to. Graphene already provides such concept in the form of the
graphl.Undefined
value, which is a good example of a value that the user could use to differentiate between an optional input being explicitly set toNone
versus not being set at all.The proposed API is a function called
set_input_object_type_default_value()
that allows the user to change the sentinel value that will be returned in optional inputs (it should be called early in the code, before anyInputObjectType
s are defined). The default value remainsNone
, aligning with the current behavior, so as not to break existing code that relies on the current assumption.(Next steps and parting thoughts)
Moving forward, I believe it'd be best to discuss around introducing a well documented breaking change that fixes this behavior altogether, eliminating such possibility. But the current PR should allow us to keep making progress while bigger fish are being fried 🐟 🧑🍳
Thanks!