Skip to main content

introduce ExecuteGroupedFieldSet, CollectRootFields and CollectSubfields

At a glance​

Timeline​

Rather than merging subSelectionSets of a field set using MergeSelectionSets and then calling CollectFields, this PR introduces CollectSubfields allows the field set's groupedSubfieldSet to be calculated directly.

The reference implementation already uses this algorithm so that this change actually aligns the specification to the reference implementation, and is ipso facto non-breaking.

Motivation: reformulating the specification in this manner may be helpful if the specification were ever to be altered such that additional state beyond the current selection set were to be required to calculate the response, i.e. if it were to be required to know the originating selectionSet of a given field within the fieldSet for determining when to communicate a reference signal. In such a scenario, it may still be quite possible to merge the set of requested data from a field set's subSelectionSets, but it may not be possible to express that merged data as an equivalent selectionSet.

In particular, currently:

{
  a {
    subfield1
  }
  ...ExampleFragment
}

fragment ExampleFragment on Query {
  a {
    subfield2
  }
  b
}

For the given set of fields:

a {
  subfield1
}
a {
  subfield2
}

These can currently be trivially merged as:

a {
  subfield1
  subfield2
}

However, the requested information for a in:

{
  a {
    subfield1
  }
  Ref1 { completed } : ...ExampleFragment
}

fragment ExampleFragment on Query {
  a {
    subfield2
  }
  b
}

cannot be contained in a merged selection set under A, because some of those fields will be related to Ref1 and some will not. The requsted information can still be merged, but it cannot be expressed in selection set format.