[
https://issues.apache.org/jira/browse/SLING-9550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146318#comment-17146318
]
Bertrand Delacretaz edited comment on SLING-9550 at 6/26/20, 2:28 PM:
----------------------------------------------------------------------
At [commit
1f61560|https://github.com/apache/sling-org-apache-sling-graphql-core/commit/1f615603fae31595aecb98027ec857dca0282500]
the
[feature/SLING-9550|https://github.com/apache/sling-org-apache-sling-graphql-core/tree/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}
was (Author: bdelacretaz):
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)
