codegen not generating custom scalar types. about sbt-graphql

[anzecesar]

Yes, according to graphql docs:

Then it's up to our implementation to define how that type should be serialized, deserialized, and validated. For example, you could specify that the Date type should always be serialized into an integer timestamp, and your client should know to expect that format for any date fields.

The sad part here is as you pointed out already, there is no way to infer this serialisation just from the schema alone. DateTime could be encoded as a String or as an Int or anything in between :). So much of strongly typed 😂

I think your solution in #29 makes most sense.

I could give implementing it a shot :).

I'm closing this in favour of #29.

[muuki88]

Thanks for your detailed bug report 👍

We don't have any test for scalar type definitions like you posted. It could very well be that this feature is missing.

Do you have the time and interest to do a pull request 😎? I'll be more than happy to help you 🤗

[jonas]

Yes, scalar types are currently ignored.

• https://github.com/muuki88/sbt-graphql/blob/master/src/main/scala/rocks/muki/graphql/codegen/TypedDocumentParser.scala#L54

I don't remember how sangria represents it should be a matter of generating a type alias similar to how it is done for the built-in ID scalar type.

• https://github.com/muuki88/sbt-graphql/blob/master/src/main/scala/rocks/muki/graphql/codegen/TypedDocumentParser.scala#L196

[muuki88]

@jonas is right. The type alias makes sense if it's actually only an alias. On the other hand there a some use cases for custom scalars, e.g. DateTime. Sangria's section on custom scalar types describes how to implement them.

For custom scalar types we would need additional imports ( #29 ) as we cannot generate code for something we don't know ;)

[muuki88]

Thanks a lot @anzecesar 😊 looking forward to a pull request. If you need any help, just open the pull request with the code you already have and we are more than happy to help 😊