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
Scalar's serialize, parseValue and parseLiteral #500
Comments
serialize: gets invoked when serializing the result to send it back to a client. parseValue: gets invoked to parse client input that was passed through variables. parseLiteral: gets invoked to parse client input that was passed inline in the query. |
Correct. parseValue gets a plain JS object, and parseLiteral gets a value AST. |
Sorry if I'm re-opening this but I'm working again on scalars and there's something I can't understand event reading your code:
Thanks, |
@adriano-di-giovanni I know it is from long time ago. I came here by search, so I thought I might answer.
No. The response in GraphQL is JSON. So, you could return anything that can be represented as such. Number, String, Array or simply JS Object.
Yes, I believe. In a resolver function, we don't care whether the value of a type was inline or came from |
Looking at the This constraint doesn't seem to be enforced during serialization though, so problems occur only when Reading around the spec and the source code I wasn't able to figure out what's the intended behaviour though. Should scalars ultimately resolve to either ~nulls, booleans, numbers or strings? |
Sorry, I still don't understand. Should we implement two methods or just only one of them? |
@helfer thx. I am clear |
Don't get the API design purpose too. If the |
@timqian you can refer to my answer on stackoverflow. The input for those two methods are different. One receives AST, the other one receives parsed javascript object (if you want to call it JSON). |
I'm also curious by the API design purpose just like @timqian , if someone could elaborate more about why this should be handled by the library's user instead of the library itself, that would be great! However, there is the astFromValue helper function though, so one can provide a single logic only on the parseLiteral and simply pass the value from the parseValue to the helper first then pass it to the parseLiteral. |
Disclaimer: Maybe not the best example but it's something I come up with in 3AM after I returned back from pub 🍻 @boostwilliam For example, let's take JSON.parse('18446744073709551616')
// 18446744073709552000 So your only option is to send such values as strings. {
foo(arg: 18446744073709551616)
} Our goal is to write new GraphQLScalar({
name: 'Int64',
parseLiteral(ast) {
if (ast.kind !== Kind.INT) {
throw Error('...');
}
return BigInt(ast.value);
}
parseValue(value) {
if (typeof value !== 'string') {
throw Error('...');
}
return BigInt(value);
}
}) It's just one example from the top of my head there are a few other reasons for why |
I was thinking about this issue for the last few months and I agree that in the majority of cases you don't need separate |
Please, correct me if I'm wrong
serialize
gets invoked when we query data (i.e. we format a Date from MongoDB to ISO 8601)parseValue
gets invoked when we mutate data (i.e. we get a value from anInputType
and try to coerce it to a Javascript value.What about
parseLiteral
?Thanks
The text was updated successfully, but these errors were encountered: