Graphql-tools: Implementing parameters on scalar types instead of Type fields
I have been experimenting with custom scalar types, and I'm wondering if the implementation could be extended to include/specify any query parameters. For example, if a Type has more than one representation, you need to add a parameter to your Type field, and implement the functionality in the resolvers. It would be great if it was possible to define these parameters in the scalar Type instead. Would that be a viable feature request?
The idea is that any parameters defined on the scalar Type get added to the field automatically, and that serialize method would receive these parameters.
For example. Let's take a temperature scalar. With a Celcius and Fahrenheit representation. If you want to achieve this now, you would use a Float field, add a parameter to the field, and put the conversion in the resolver. It would be great if that could all be contained within the GraphQLScalarType Temperature.
kbrandwijk
All 7 comments
kbrandwijk
on 16 Dec 2017
@kbrandwijk I think that could be done with schema directives as well, I want to add more powerful handling for those to this package soon.
stubailo
on 18 Dec 2017
@stubailo There's something to be said for using directives. For me, the most important part is that I do not want to have many different places to implement common functionality. So my best case scenario is still if graphql-js would support passing in arguments (or directives for that matter) to the scalar type methods.
The second best scenario would be if I can implement a single resolver for a directive, that would work on every field I apply it to, preferably with some Type selector (like how visit works for example).
kbrandwijk
on 18 Dec 2017
Type selector? Like, apply a directive to every field of a type?
stubailo
on 18 Dec 2017
No, that's not what I meant. I meant that if I apply the directive to fields of different Types, I would get a nice API to define the implementation per Type. That's why I mentioned visit (although that uses field Kind, not field Type).
Let's say I have a format directive, that I apply to fields of type String, Url, Geopoint. Now it would be helpful if I could easily specify the implementation per Type, instead of only having a single resolve function, and a switch statement on Type.
This is exactly the reason why I would like to get parameter/directive information in the custom Scalar Type, instead of the other way around and switching on Type in a directive resolver. It just not easily manageable.
kbrandwijk
on 18 Dec 2017
Yeah, I see what you mean. But that's exactly the kind of stuff graphql-tools was originally designed to address, so let's see if we can find an abstraction to make it work! I'm interested in adding some abstractions around schema directives in the next week or so, would love to work together if you're interested!
stubailo
on 18 Dec 2017
Absolutely! The issue I linked on graphql-js contains some more use case descriptions.
kbrandwijk
on 18 Dec 2017
Related issues
MehrdadKhnzd
路
3Comments
alfaproject
路
4Comments
adamkl
路
3Comments
BassT
路
3Comments
freiksenet
路
4Comments
Most helpful comment
No, that's not what I meant. I meant that if I apply the directive to fields of different Types, I would get a nice API to define the implementation per Type. That's why I mentioned
visit(although that uses field Kind, not field Type).Let's say I have a format directive, that I apply to fields of type
String,Url,Geopoint. Now it would be helpful if I could easily specify the implementation per Type, instead of only having a single resolve function, and a switch statement on Type.This is exactly the reason why I would like to get parameter/directive information in the custom Scalar Type, instead of the other way around and switching on Type in a directive resolver. It just not easily manageable.