Skip to content

Commit 2dc2df2

Browse files
committed
Updated RFC doc to prep for WG
1 parent 3932242 commit 2dc2df2

File tree

1 file changed

+18
-13
lines changed

1 file changed

+18
-13
lines changed

rfcs/FragmentArguments.md

Lines changed: 18 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -289,19 +289,24 @@ fragment Bar($x: Int!) on User {
289289
## Updated Validation: Overlapping Fields Can Be Merged
290290

291291
Previously, fragment spreads didn't have to be considered as unique selections
292-
in the overlapping field merging algorithm. However, the algorithm still
293-
de-duplicated common fragment spreads.
294-
295-
With this change, we can either just treat deduplicated fragment spreads as
296-
being keyed by (name, arguments) rather than just by name, and then apply the
297-
arguments when traversing the child selection set.
298-
299-
Alternatively, and as implemented in
300-
[graphql-js](https://github.com/graphql/graphql-js/pull/3152), we can both keep
301-
track of the updated fragment keys and also short-circuit whenever we encounter
302-
two fragments with the same name but different arguments.
303-
304-
## WILL NOT IMPLEMENT Validation Rule: Argument Uniqueness
292+
in the overlapping field merging algorithm. However, in practice the algorithm,
293+
but not the spec, still de-duplicated common fragment spreads.
294+
295+
With this change, we can just treat deduplicated fragment spreads as being keyed
296+
by (name, arguments) rather than just by name. When visiting child selections,
297+
we need to apply any fragment argument values (basically replace them with
298+
either variable or const values), and then any time we encounter duplicated
299+
fragment spreads with different arguments within merging selections, we consider
300+
that invalid.
301+
302+
We _could_ just allow field merging rules to apply, but stopping the validation
303+
when same-named fragment spreads with different args are discovered helps
304+
provide much better error messaging and root-causes the issue: the issue isn't
305+
that you reached the same field in the same fragment twice, but rather than you
306+
reached the same fragment spread with different arguments, which will induce
307+
those two usages to be merging the same field with different arguments.
308+
309+
## WILL NOT IMPLEMENT Validation Rule: Document Argument Uniqueness
305310

306311
If the client pre-server compiler rewrites an operation, it's possible to end up
307312
with a selection set that violates

0 commit comments

Comments
 (0)