Open lrzp opened 2 years ago
Do you have a case for using Meta
's fields that doesn't have an alternative? If the feature is unusable right now, but no one else noticed there might be a need to re evaluate the need for this field as a whole.
In my case, it was a creation of input fields dynamically based on a subset of model fields. I've tried to reproduce the Node behavior to keep things simple and DRY.
Node behavior:
class MyNode(DjangoObjectType):
class Meta:
model = MyModel
fields = tuple_of_boolean_fields
How I want Input to work (according to docs):
class MyInput(graphene.InputObjectType):
class Meta:
fields = {field: graphene.Boolean() for field in tuple_of_boolean_fields}
How it has to be solved right now:
class MyInput(graphene.InputObjectType):
field1 = graphene.Boolean()
field2 = graphene.Boolean()
field3 = graphene.Boolean()
field4 = graphene.Boolean()
field5 = graphene.Boolean()
This can be solved with some meta-programing but it leaves us with an overly complicated, hard-to-read hack.
In
InputObjectType.__init_subclass_with_meta__
, thefields
of theMeta
class (passed as anoptions
arg) are never referenced. This in effect just skips them completely wich stands in contradiction to the docstring.InputObjectType
has to be subclassed and__init_subclass_with_meta__
has to be extended for this feature to work, like in graphene.tests.issues.test_720.If this is accepted I can do a PR for this along the lines: