Skip to content

Commit 4a04fff

Browse files
committed
add note
1 parent e67feb2 commit 4a04fff

File tree

1 file changed

+15
-1
lines changed

1 file changed

+15
-1
lines changed

spec/Section 5 -- Validation.md

+15-1
Original file line numberDiff line numberDiff line change
@@ -1890,7 +1890,8 @@ variable.
18901890

18911891
IsVariableUsageAllowed(variableDefinition, variableUsage):
18921892

1893-
- If {variableUsage} is nested in a custom scalar literal value, return {true}.
1893+
- If {variableUsage} is nested within a custom scalar literal value, return
1894+
{true}.
18941895
- Let {variableType} be the expected type of {variableDefinition}.
18951896
- Let {locationType} be the expected type of the {Argument}, {ObjectField}, or
18961897
{ListValue} entry where {variableUsage} is located.
@@ -1981,6 +1982,19 @@ query nonNullListToList($nonNullBooleanList: [Boolean]!) {
19811982
}
19821983
```
19831984

1985+
When using variables nested within custom scalars literals, the expected type is
1986+
unknown, and variable usages are always allowed. The actual value is coerced at
1987+
runtime using the custom scalar coercion rules. In the following case, the
1988+
`user` argument expects a `JSON` custom scalar, and it is valid for it to
1989+
reference variables:
1990+
1991+
```graphql example
1992+
mutation updateUserName($name: String!) {
1993+
# This usage of the $name variable is valid
1994+
updateUser(user: { name: $name })
1995+
}
1996+
```
1997+
19841998
However, a nullable list cannot be passed to a non-null list:
19851999

19862000
```graphql counter-example

0 commit comments

Comments
 (0)