-
Notifications
You must be signed in to change notification settings - Fork 7
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
add implementation guide #2
Conversation
I understand the distinction between Literal and Value coercion you're trying to make, but ultimately I think they're the same thing. It's just that a literal can only be one of the graphql AST types (string, int, etc) whereas a variable value can be of any type supported by the transport. In other words, I don't think it should be possible to specify a scalar which treats string literals differently from string variables. |
} | ||
``` | ||
|
||
## Result Coercion: Serialize or not |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this go under implementation guidelines? It is an implementation thing.
@eapache Maybe I was not perfectly clear but the Ast for a custom Scalar can be arbitrary as long as it is valid Syntax. Value Coercion can take "anything" that is meaningful for the custom Scalar and is very much implementation specific to the programming language. The guideline here is: all values that makes sense and can be converted/interpreted without surprises or pitfalls. In a Specification for a custom Scalar you have to be very clear around the syntax that the Scalar should accept because it is cross implementation valid. For the Value Coercion you can only give very general recommendations. For example for Hope that make sense. |
Ah that makes sense. But since Value Coercion can take anything, Literal Coercion is still basically just a subset of Value Coercion? |
|
||
https://www.graphql.de/blog/scalars-in-depth/ | ||
|
||
https://www.apollographql.com/docs/graphql-tools/scalars/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This link is outdated :)
@eapache Only in the sense that both feed into to the resolver as arguments. Sure, you are free to decide to implement them very similar or maybe even in one method, but there are fundamental differences: Literal Coercion is clearly defined in the Scalars spec and must be implemented as defined. Value Coercion is not defined in the Scalars spec as it is implementation specific. You will change it more often: for example when JavaScript introduces a new Regarding the implementation of both methods: one big difference is that for complex Ast inputs you need to take care of variable references for literal coercion. For example: in terms of function signature (pseudo code):
Does this make the differences more clear? |
This is outdated and will be replaced with a new setup and implementation guide |
This is just mdx. It was originally written for gatsby, but being mostly just markdown it can be easily ported to whatever the build/publish system it.
This PR is for discussing the content.
A rendered version of it can be found here: https://www.graphql-scalars.com/scalars-guide