Replace ExecuteSelectionSet with ExecuteGroupedFieldSet
#1039
Conversation
✅ Deploy Preview for graphql-spec-draft ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
| - For each {field} in {fields}: | ||
| - Let {fieldSelectionSet} be the selection set of {field}. | ||
| - If {fieldSelectionSet} is null or empty, continue to the next field. | ||
| - Append all selections in {fieldSelectionSet} to {selectionSet}. | ||
| - Return {selectionSet}. |
There was a problem hiding this comment.
Perhaps we should call this fieldGroupedFieldSet rather than subGroupedFieldSet as when comparing here between the non prefixed groupedFieldSet and this prefixed grouped field set, they both refer to subfields, just one is from a single node and one is the merged result.
There was a problem hiding this comment.
Perhaps childGroupedFieldSet? fieldGroupedFieldSet sounds to me like a "field-grouped field set" rather than a "field's grouped-field-set".
There was a problem hiding this comment.
Hmm, child has the same problem, but maybe if we change fieldSelectionSet in tandem that would work anyway through some context signaling
benjie
force-pushed
the
benjie/incremental-common
branch
from
4d62b8b
to
b342b58
Compare
|
(Rebased on |
benjie
force-pushed
the
benjie/incremental-common
branch
from
b342b58
to
a52310e
Compare
|
(Rebased on |
|
The only issue I noticed when working on incremental delivery, which depends on this, is the ordering of where the collect fields algorithm shows up — as it is now still in the original place, but it is used much earlier. This gets more complicated with incremental delivery as the incremental delivery plan building and execution has the same issue which exacerbates the ordering conundrum. Might we consider moving collect fields earlier or into its own section as part of this PR? |
|
@yaacovCR Just to check I understand, you mean specifically reordering the sections in specification but keeping the algorithm steps the same, rather than reordering the steps within the algorithms, right? Maybe you'd like to make a PR to this branch which does your proposed re-arrange without any extraneous edits? |
|
as just one option. With incremental delivery, the Field Collection subsection may be supplemented by additional incremental-delivery specific subsections |
|
@benjie we need to formally define "grouped field set" in Section 2 "Language". You might have done so in a prior PR that I missed. Here is the link to us defining "section sets" in section 2 https://spec.graphql.org/draft/#sec-Selection-Sets |
Essentially this PR raises the concept of "grouped field sets" to be a top-level concept, and replaces the
ExecuteSelectionSetmethod withExecuteGroupedFieldSet(which essentially just drops the first line ofExecuteSelectionSet, which was responsible for producing the grouped field set to be executed). It then refactors the rest of the spec to accommodate this change, reducing the repetition inExecuteQuery,ExecuteMutationandExecuteSubscriptionEvent; and removingMergeSelectionSets(which generated a "virtual" selection set to accomodate theExecuteSelectionSetmethod), instead adding aCollectSubfieldsalgorithm which generates a grouped field set directly, ready for execution.I extracted this common refactoring from a number of my attempts to write spec changes for the
@deferand@streamdirectives - it turns out that this refactoring of the spec was always needed as a base for my changes. Similarly, @yaacovCR found similar in his attempts to address this same problem, and raised #999 extracted from his solution. This PR was introduced independently of #999 (other than using theCollectSubfieldsalgorithm name) however there is significant alignment, so @yaacovCR suggested that I raise it as an alternative PR.It may be easier to review this PR in "split" view rather than "unified" view.