Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Tagged type #733

Closed
wants to merge 45 commits into from
Closed
Show file tree
Hide file tree
Changes from 44 commits
Commits
Show all changes
45 commits
Select commit Hold shift + click to select a range
3d43179
First pass
benjie Jun 12, 2020
d411b60
More edits
benjie Jun 12, 2020
16de657
Input coercion
benjie Jun 12, 2020
a73d1cc
Change tagged "fields" to "members"
benjie Jul 3, 2020
ceb81d5
Merge branch 'master' into tagged-type
benjie Jul 15, 2020
e65126d
Sync type system
benjie Jul 15, 2020
a4c4578
Factor in review feedback from @spawnia
benjie Jul 21, 2020
c31ddc4
Merge branch 'master' into tagged-type
benjie Sep 1, 2020
55feb1c
Move TaggedMemberDefinition
benjie Sep 1, 2020
f786f1c
Add TAGGED_MEMBER_DEFINITION directive location
benjie Sep 1, 2020
5906cd0
Reorder so tagged types comes after interfaces/unions
benjie Sep 1, 2020
bd88e51
Edit out comma that snuck in
benjie Sep 1, 2020
514bb72
Add word 'concrete'
benjie Sep 1, 2020
4768d8d
Define member field
benjie Sep 1, 2020
95ccf95
Add Lee's note
benjie Sep 1, 2020
88f983b
Lee's rewording
benjie Sep 1, 2020
a6486ce
Add mutually exclusive tagged type example with distinct types
benjie Sep 1, 2020
cf8d7a6
Make it clear Tagged type fields can be of any type.
benjie Sep 1, 2020
a09b30a
s/objects/results
benjie Sep 1, 2020
c81ebb1
:
benjie Sep 1, 2020
5dcb81b
Checking for one key is easier than validating the given keys (maybe)
benjie Sep 1, 2020
71ca892
nit
benjie Sep 1, 2020
ce213bb
Allow @deprecated on TAGGED_MEMBER_DEFINITION
benjie Sep 1, 2020
7ac7532
Reword note on tagged member deprecation
benjie Sep 1, 2020
0ae9ba8
Add note that added members must not make the tagged type invalid
benjie Sep 1, 2020
361a235
Fix case
benjie Sep 1, 2020
a1705b5
Remove duplicate
benjie Sep 1, 2020
8807c1c
Reword to follow Lee's example
benjie Sep 1, 2020
61b7b8f
Reposition TAGGED to always be between Union and Enum.
benjie Sep 1, 2020
285673a
Terran -> Earthling
benjie Sep 1, 2020
d9820c4
Make header consistent
benjie Sep 1, 2020
f91d8ba
__Type represents all named types in the system
benjie Sep 1, 2020
82151ba
Apply Lee's suggestion
benjie Sep 1, 2020
02a2a93
Combine
benjie Sep 1, 2020
5bdcc30
Use 'field' rather than 'key'
benjie Sep 1, 2020
88e506a
GetTaggedMember[Field]Name
benjie Sep 2, 2020
fee5ca3
__[Tagged]Member[Field]
benjie Sep 2, 2020
0f5d7cc
TAGGED_MEMBER_[FIELD_]DEFINITION
benjie Sep 2, 2020
94a67b7
TaggedMember[Field]Definition/TaggedMember[Field]sDefinition
benjie Sep 2, 2020
f66e237
taggedMember[Field]Name
benjie Sep 2, 2020
e308258
Fix definition ordering
benjie Sep 2, 2020
6fa34c2
Members -> member fields
benjie Sep 2, 2020
4bf67b4
Grammar
benjie Sep 2, 2020
5afea0b
Fix incorrect capital
benjie Sep 2, 2020
ced63be
Separate input and output tagged types
benjie Jan 21, 2021
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 14 additions & 0 deletions spec/Appendix B -- Grammar Summary.md
Original file line number Diff line number Diff line change
Expand Up @@ -233,6 +233,7 @@ TypeDefinition :
- ObjectTypeDefinition
- InterfaceTypeDefinition
- UnionTypeDefinition
- TaggedTypeDefinition
- EnumTypeDefinition
- InputObjectTypeDefinition

Expand All @@ -241,6 +242,7 @@ TypeExtension :
- ObjectTypeExtension
- InterfaceTypeExtension
- UnionTypeExtension
- TaggedTypeExtension
- EnumTypeExtension
- InputObjectTypeExtension

Expand Down Expand Up @@ -285,6 +287,16 @@ UnionTypeExtension :
- extend union Name Directives[Const]? UnionMemberTypes
- extend union Name Directives[Const]

TaggedTypeDefinition : Description? tagged Name Directives[Const]? TaggedMemberFieldsDefinition?

TaggedMemberFieldsDefinition : { TaggedMemberFieldDefinition+ }

TaggedMemberFieldDefinition : Description? Name : Type Directives[Const]?

TaggedTypeExtension :
- extend tagged Name Directives[Const]? TaggedMemberFieldsDefinition
- extend tagged Name Directives[Const]

EnumTypeDefinition : Description? enum Name Directives[Const]? EnumValuesDefinition?

EnumValuesDefinition : { EnumValueDefinition+ }
Expand Down Expand Up @@ -331,6 +343,8 @@ TypeSystemDirectiveLocation : one of
`ARGUMENT_DEFINITION`
`INTERFACE`
`UNION`
`TAGGED`
`TAGGED_MEMBER_FIELD_DEFINITION`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we distinguish this from FIELD_DEFINITION and ARGUMENT_DEFINITION? I can't immediately think of a use case for a directive that would apply on normal fields or normal arguments, but would be incoherent on a tagged member field?

If we don't define it specially, that weighs in on the input-vs-output question as well; for a tagged member field, which directives does it permit? Field directives or argument directives? If it's to be used in both input and output, it has to permit both; is that reasonable?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FIELD_DEFINITION, ARGUMENT_DEFINITION and INPUT_FIELD_DEFINITION have separate entries because they are separate things, tagged member fields are also separate to all of these, they're neither FIELD nor INPUT_FIELD, so I think it makes sense to have a separate directive location for them. As you rightly point out member fields are different because they could be for input or output, so it's clear that using directives targetted at fields or arguments may not make sense for tagged, so again differentiation is critical.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't immediately think of a use case for a directive that would apply on normal fields or normal arguments, but would be incoherent on a tagged member field?

directive @required(with: String!) on ARGUMENT_DEFINITION, INPUT_FIELD_DEFINITION

input UpdateUser {
  name: String
  password: String
  passwordConfirmation: String @required(with: "password")
}

`ENUM`
`ENUM_VALUE`
`INPUT_OBJECT`
Expand Down
2 changes: 1 addition & 1 deletion spec/Section 2 -- Language.md
Original file line number Diff line number Diff line change
Expand Up @@ -607,7 +607,7 @@ can be used in the context of querying a `User`.
Fragments cannot be specified on any input value (scalar, enumeration, or input
object).

Fragments can be specified on object types, interfaces, and unions.
Fragments can be specified on object types, interfaces, unions, and tagged types.

Selections within fragments only return values when the concrete type of the object
it is operating on matches the type of the fragment.
Expand Down
Loading