Optional Query Arguments Question

[Teddy-Schmitz]

If a string argument to a query is declared optional its a Pointer type. But it looks like if its not passed in, the generated code marshals it into a string with the value of "null" so the pointer is never actually nil. I was doing nil checks to see if a string was sent but this seems to break this as its always set to "null".

[Teddy-Schmitz]

This looks like it happens because the incoming query has declared a variable and passed that into the query, but provided no actual query variable for it. The reason I'm doing it this way is to paginate through the results. So I declare query ($hash: String!, $cursor: String) but don't actually send the cursor until the user clicks next page.

[vektah]

It should work now, and defaults should work correctly too.

The "null" comes from very strong coercion, I wonder if I should just delete that.

[Teddy-Schmitz]

I guess it depends on how closely you want to follow neelance's library. But to me it makes more sense that since its a pointer a nil value means unset versus "null" which would be something set explicitly in the incoming query.

[vektah]

after that PR it should work like this:

args = {}, a = nil
args = {a: "hello}; a = "hello"
args = {a: 1.2}; a = "1.2"
args = {a: true}; a = "true"
args = {a: null}; a = "null"

http://facebook.github.io/graphql/draft/#sec-String

GraphQL servers should coerce non‐string raw values to String when possible otherwise they must raise a field error. Examples of this may include returning the string "true" for a boolean true value, or the string "1" for the integer 1.

I think the float/int coercion makes sense. Null still seems poorly defined.

I just found https://github.com/graphql-cats/graphql-cats, I have to find a way to validate against that.