-
Notifications
You must be signed in to change notification settings - Fork 828
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
types: add option for strict connection types #1504
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #1504 +/- ##
=======================================
Coverage 96.01% 96.01%
=======================================
Files 51 51
Lines 1755 1755
=======================================
Hits 1685 1685
Misses 70 70
☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR! Can you please add some test cases for this, testing the schema generation? 😊
@erikwrede does that look like what you meant? |
@erikwrede it looks like the checks will never complete because the python 3.6 test workflow no longer exists after https://github.com/graphql-python/graphene/pull/1507/files but the GitHub repo settings still require that workflow to run |
This PR adds a
strict_types
meta option to the relayConnection
class to simplify the use case identified in this issue: graphql-python/graphene-django#901Default of
False
is the old behavior, and when set toTrue
generatedTConnection
types will be typed asedges: [TEdge!]!
instead ofedges: [TEdge]!
andTEdge
will havenode: T!
instead ofnode: T
.This avoids duplicating logic and string descriptions for subclasses which just want to implement this common behavior. If this behavior is deemed desirable by default it would be trivial to flip the flag's default or remove it entirely. It only make the types stricter so it oughtn't break any existing code (though it will cause unexpected changes to user's schema's nonetheless, which is why I kept the default to
False
).