[ https://issues.apache.org/jira/browse/SLING-9550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146318#comment-17146318 ]
Bertrand Delacretaz commented on SLING-9550: -------------------------------------------- At [commit 1f61560|https://github.com/apache/sling-org-apache-sling-graphql-core/commit/1f615603fae31595aecb98027ec857dca0282500] the feature/SLING-9550 branch includes a {{CustomScalarsTest}} that demonstrates custom scalars supported by {{SlingScalarConverter}} services., using the following schema in {{scalars-schema.txt}}: {code} scalar URL scalar UppercaseString type Query { address (url : URL) : AddressInfo @fetcher(name:"scalars/address") } type AddressInfo { hostname: UppercaseString url: URL } {code} > Support custom GraphQL Scalars > ------------------------------ > > Key: SLING-9550 > URL: https://issues.apache.org/jira/browse/SLING-9550 > Project: Sling > Issue Type: Task > Components: GraphQL > Affects Versions: GraphQL Core 0.0.2 > Reporter: Bertrand Delacretaz > Assignee: Bertrand Delacretaz > Priority: Major > > We should support [custom > scalars|https://www.graphql-java.com/documentation/v13/scalars/] in the > GraphQL Core, which is a fancy way to say "custom data types". > [https://github.com/graphql-java/graphql-java-extended-scalars] has examples > of those. > After a quick brainstorm with a colleague I think we need to following: > * A way to provide "named type converters" that define the Scalar names and > how to parse and serialize them. > * A way to define "scalar namespaces" in the schemas, to avoid name > collisions if multiple Scalars with the same name are used in different > applications. That's probably a directive like the {{@fetcher}} that we > already use, maybe something like > {{@namespace(scalars='com.example.scalars')}} > So far we've been able to avoid exposing the {{graphql-java}} APIs in the > GraphQL Core APIs but I'm not sure if it makes sense here, will need to > explore. If our APIs expose {{graphql-java}} APIs they should be under a > {{sling.graphql.api.graphqljava}} package to make that clear. > As an example use case we might add author name and email information to the > sling-samples website example, using a custom scalar for the email. -- This message was sent by Atlassian Jira (v8.3.4#803005)