-
Notifications
You must be signed in to change notification settings - Fork 93
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
WIP Custom Scalar Proof of Concept #1988
Conversation
Thanks, I'm gonna be playing around with this and throwing some notes at you.. :)
That is because of the |
server/implementation/src/main/java/io/smallrye/graphql/scalar/custom/IntCoercing.java
Outdated
Show resolved
Hide resolved
server/implementation/src/main/java/io/smallrye/graphql/scalar/custom/CustomFloatScalar.java
Outdated
Show resolved
Hide resolved
Also, could you add a short story about how to use it in a new file in the |
Thank you for the tip on Quarkus' requirements for bytecode recording. We have also written a test app for this and it should be working as expected now. I have also added a feature doc along with some java docs where requested. Happy to add more where it is appropriate to do so. |
...chema-builder/src/main/java/io/smallrye/graphql/schema/creator/type/CustomScalarCreator.java
Outdated
Show resolved
Hide resolved
server/implementation/src/main/java/io/smallrye/graphql/scalar/custom/CustomStringScalar.java
Outdated
Show resolved
Hide resolved
Thanks! |
What: This PR allows users to define custom scalars based on GraphQL's
String
,Int
, andFloat
literal primitives. This design might also be extended to support custom scalars based on JSON literals in the future.Why: Current functionality supports mapping object fields to the scalars that are supported by smallrye-grapqhl, however a user cannot define their own scalars in the resulting GraphQL schema.
How: This PR is suggesting a new annotation of
@CustomScalar("ScalarName")
and a limited set of interfaces representing each GraphQL literal primitive type.The following is an example of an alternative BigDecimal scalar that serializes to a GraphQL String instead of a Float.
Disclaimer: This is just a suggestion for how this might be done and we are very open to design feedback. Would also like to note that the exception handling was purposefully left undone as we did not want to infer how the exception handling should be done. As we move towards a final design we would appreciate any input on exception handling best practices for this project as well.