Be more permissive of duplicate fields with different selections
- Dominant language
- Go
- Stars
- 1.3k
- Forks
- 143
- Avg merge
- 4h 50m
- Merged PRs (30d)
- 1
Description
GraphQL allows you to do this:
```graphql
query {
myField {
# these two get merged:
subField { subSubField1 subSubField2 }
subField { subSubField3 subSubField4 }
}
}
```
and even this:
```graphql
query {
myField {
subField { subSubField1 subSubField2 }
... on OnePossibleConcreteType {
subField { subSubField3 subSubField4 } # merged in if the concrete type matches
}
}
}
```
(Well, it sometimes lets you do that. [The rules](https://spec.graphql.org/draft/#FieldsInSetCanMerge()) are very arcane.))
For now, to simplify things, I've simply disallowed any duplicate fields of composite type in genqlient. There's no structural limitation preventing us from adding support, if we do find it useful, we'd just need to do more complicated merging in `convertSelectionSet`. (there would be some subtleties to handle around type naming.) But my guess is this is quite rare (and easy enough to work around).
Note that we do already allow duplicated leaf fields, because they're much easier to deduplicate. We also allow duplicated fields if at least one is in a name fragment, because in that case we needn't merge the fields at all.
Contributor guide
Research direction
Start by reading convertSelectionSet and the linked GraphQL FieldsInSetCanMerge rules. Done means composite duplicate fields can be merged across ordinary selections, while existing leaf-field and name-fragment behavior remains intact, including concrete-type naming subtleties.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, graphql
- Domain
- api, tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100