-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[RFC] Inherit fields from interface automatically #881
Conversation
|
This has been discussed before and rejected. See one comment explaining rationale here #500 (comment) However I appreciate the work in collecting all details about this RFC in one file. I'm about to move all RFCs to another repository so merging this in advance of doing that |
Thanks @leebyron for your reaction. I understand that there are certain objections against automatically inheritance (as for example outlined in your linked comment). But as you see in the reactions to your comment and in #533 (which is under the top 15 of issues with +1), not everyone agrees with the point of favoring readability over not-repeat-yourself. In my opinion, this comes also from the fact that IDE support for graphql caught-up and jumping around the schema is nicely supported right now; in my opinion there is also a shift in using the graphql schema more for writing and using other tools for exploring and reading (like graphql playground, automatically generated docs etc). Due to these natural difference between philosophies, I phrased this RFC as an optional extension - so if a team decides it's more suitable for them to keep the current behavior than that's still possible. For these reasons I hope the decision to reject this proposal can be revisited. If not, I would suggest to close #533 as well. Do you think it would make sense for me to join the next working group meeting to discuss this points in person? |
You're absolutely welcome to join the next working group meeting. Proposals typically only move forward when their champions bring them to WG meetings to work through the details. |
## Evaluation against [guiding principles](https://github.com/graphql/graphql-spec/blob/main/CONTRIBUTING.md#guiding-principles) | ||
- Backwards compatibility: ✅ | ||
|
||
Existing queries and schema are still valid. |
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.
Yes, but some GraphQL frameworks/parsers most likely adhere to current "hard" rules about inheriting fields from interfaces so there may be problems when trying to use them with the "new lightweight" schema.
This is currently a Stage 0: Strawman proposal looking to advance to Stage 1.
The RFC is mainly based on the discussion in the related issues #533 #500 and graphql/graphql-js#703.
If someone has additions or clarifications, please feel free to edit the added document directly (if you have the right) or open a PR against my fork. Many thanks in advance!
I hope it is okay that took some of the examples and formulations almost verbatim from the above issues, and expanded on them in form of a RFC. Also the contribution process is not completely clear to me, so please forgive if I overlooked important steps along the way.