Improve how we determine types for fields that have resolvers
This was prompted by this issue: #1887
Currently there are some cases where the behaviour we have might not be what one expects. And we could also improve how we handled cases where field type and resolver type don't match.
Based on this type:
def resolver() -> another_type:
...
@strawberry.type
class Example:
field: a_typeHere's a table of the current behaviours
| field type | resolver return type | current behaviour | expected behaviour | current type | expected type |
|---|---|---|---|---|---|
| int | TypeVar("T") | no error | no error [1] | int | int |
| int | int | no errors, no warnings | no errors, no warnings | int | int |
| int | missing | no errors, no warning | no error, maybe a (opt-out) warning? | int | int |
| int | str | no errors, no warnings | error | str | int |
[1] recently fixed here: #1891
strawberry-graphql / strawberry
A GraphQL library for Python that leverages type annotations 🍓
4.0k
How does funding with Polar work?
1
Pay now to fund the work behind this issue.
2
Get updates on progress being made.
3
Maintainer is rewarded once the issue is completed.
FAQ
Backer
You're funding impactful open source efforts
Contributor
You want to contribute to this effort
Maintainer
You want to get funding like this too