Strawberry doesn't actually type check the values returned from
resolvers -- the "self" in resolvers is really just whatever object the
parent resolver returned, transparently forwarded by strawberry. Before
this change, all of our resolvers return (and in turn only support)
"self" being an instance of a sqlalchemy model, not the strawberry type.
At best, that's confusing, but at worst, it doesn't allow manually
defined resolvers on a mapped type to call sibiling resolvers. E.g.
imagine a user-defined resolver:
This fails, because the sqlalchemy model type has no
"resolve_other_field" defined, which is perplexing, because it seems
like it should be defined. The only way to call it is like:
MyModel.resolve_other_field(self, info), but IMO this unnecessarily
exposes the user to strawberry internal knowledge (static method
nonsense) that they don't need to be privvy to. By instead ensuring all
of our resolvers return the strawberry type, all the typing works just
like expected.
Strawberry doesn't actually type check the values returned from resolvers -- the "self" in resolvers is really just whatever object the parent resolver returned, transparently forwarded by strawberry. Before this change, all of our resolvers return (and in turn only support) "self" being an instance of a sqlalchemy model, not the strawberry type.
At best, that's confusing, but at worst, it doesn't allow manually defined resolvers on a mapped type to call sibiling resolvers. E.g. imagine a user-defined resolver:
This fails, because the sqlalchemy model type has no "resolve_other_field" defined, which is perplexing, because it seems like it should be defined. The only way to call it is like:
MyModel.resolve_other_field(self, info)
, but IMO this unnecessarily exposes the user to strawberry internal knowledge (static method nonsense) that they don't need to be privvy to. By instead ensuring all of our resolvers return the strawberry type, all the typing works just like expected.