Skip to content

Commit be2fbe7

Browse files
committed
add note
1 parent 35f5d07 commit be2fbe7

File tree

1 file changed

+15
-1
lines changed

1 file changed

+15
-1
lines changed

Diff for: spec/Section 5 -- Validation.md

+15-1
Original file line numberDiff line numberDiff line change
@@ -1873,7 +1873,8 @@ variable.
18731873

18741874
IsVariableUsageAllowed(variableDefinition, variableUsage):
18751875

1876-
- If {variableUsage} is nested in a custom scalar literal value, return {true}.
1876+
- If {variableUsage} is nested within a custom scalar literal value, return
1877+
{true}.
18771878
- Let {variableType} be the expected type of {variableDefinition}.
18781879
- Let {locationType} be the expected type of the {Argument}, {ObjectField}, or
18791880
{ListValue} entry where {variableUsage} is located.
@@ -1964,6 +1965,19 @@ query nonNullListToList($nonNullBooleanList: [Boolean]!) {
19641965
}
19651966
```
19661967

1968+
When using variables nested within custom scalars literals, the expected type is
1969+
unknown, and variable usages are always allowed. The actual value is coerced at
1970+
runtime using the custom scalar coercion rules. In the following case, the
1971+
`user` argument expects a `JSON` custom scalar, and it is valid for it to
1972+
reference variables:
1973+
1974+
```graphql example
1975+
mutation updateUserName($name: String!) {
1976+
# This usage of the $name variable is valid
1977+
updateUser(user: { name: $name })
1978+
}
1979+
```
1980+
19671981
However, a nullable list cannot be passed to a non-null list:
19681982

19691983
```graphql counter-example

0 commit comments

Comments
 (0)