Required fields and fragments #199
Conversation
…laar/eslint-plugin-graphql into stevehollaar-require-field-on-parent-2
stubailo
changed the title
|
cc @stevehollaar and @jnwng please give this a look if you have time! My intention is to make this rule a reliable way to ensure that a certain field is fetched ( Open to any ideas that allow more valid combinations of fields, but I'd also rather err on the conservative side. |
ghost
added
blocking
|
cc @hellendag |
CHANGELOG.md
Outdated
| - Here's a specific case which is _no longer valid_: | ||
| - `query { greetings { hello ... on Greetings { id } } }` | ||
| - This must now be written as `query { greetings { id hello ... on Greetings { id } } }` | ||
| - This is a more convervative approach than before, driven by the fact that it's quite hard to ensure that a combination of inline fragments actually covers all of the possible types of a selection set. |
There was a problem hiding this comment.
Thanks for reviewing!
| type: "TaggedTemplateExpression" | ||
| } | ||
| ] | ||
| }, |
There was a problem hiding this comment.
Also worth testing an interface where id is a shared field?
CHANGELOG.md
Outdated
| @@ -1,5 +1,13 @@ | |||
| # Change log | |||
| ### vNEXT | |||
| - BREAKING: The `required-fields` rule has been significantly changed to make it a completely reliable method of ensuring `id` fields are always requested when available. [PR #199](https://github.com/apollographql/eslint-plugin-graphql/pull/199) Here is the behavior, let's say we are requiring field `x`: | |||
| - On any field whose return type defines a field called `x`, the selection set must directly contain `x`. | |||
There was a problem hiding this comment.
x is a bit of an odd example field name. :D
src/customGraphQLValidationRules.js
Outdated
| }); | ||
| }, | ||
|
|
||
| // Every inline fragment must have an ID specified inside itself or in some |
|
(Waiting on an OK from @jnwng about whether this breaking change is fine) |
|
Published as 3.0.0! |
TODO:
Pull Request Labels