Is there possibility to use a client side directiv...

# apollo-kotlin

[Jan Skrasek]

Is there possibility to use a client side directive to map a specific field to a different type?

[Jan Skrasek]

Hm, from sources it doesn't seem to be possible.

[mbonnin]

Not really indeed, what is the use case?

[mbonnin]

The only type mapping that's allowed is for custom scalars

[Jan Skrasek]

Basically there is a single type from backend for various fields - DateTime and once we would like to parse it as Instant and another time as OffsetDateTime and convert it to LocalDateTime.

[mbonnin]

Your best bet is local schema modification and introduce new custom scalars. But really talk to your backend these are really different objects they should be modeled differently in your schema

[Jan Skrasek]

You know, corporate... 😄

[mbonnin]

You can modify the schema in the client only in the short term

[mbonnin]

And hope that this gives you enough arguments to have the backend changed at some point

[Jan Skrasek]

Thanks for suggestions 🙂

[mbonnin]

You might be interested in https://github.com/apollographql/apollo-kotlin/issues/5201

[mbonnin]

But nothing is blocking you from modifying your (local/client) schema today. You just have to remember to apply the modification every time you download a new schema, maybe a custom Gradle task with regexes or something

[mbonnin]

Also more material for your backend team, there are now official specifications for LocalDate and DateTime custom scalars: https://scalars.graphql.org/

[Jan Skrasek]

Oh, great, finally 😍

[mbonnin]

If they put the @specifiedBy directive in the scalar definition, it makes it explicit what format its using

[Jan Skrasek]

Oh, still no LocalDateTime 😞

[mbonnin]

Time is hard 😅

[mbonnin]

I haven't dug too much in these specs but maybe one of them matches the kotlinx LocalDateTime?

[mbonnin]

Nope, doesn't look like it 😞

[mbonnin]

From https://github.com/graphql/graphql-spec/issues/579:

I think having a LocalDateTime or LocalDate or LocalTime are worth having a discussion, but at the same time they can be represented as an DateTime in some way and I didn't want to make this proposal more complex.

[Stylianos Gakis]

https://kotlinlang.slack.com/archives/C01A6KM1SBZ/p1694082391465249?thread_ts=1693987357.862219&cid=C01A6KM1SBZ

Very interesting! Is there an exhaustive list somewhere for all such scalars? Or is this it, those are all the community-contributed ones? Is there a list where they’re all together? Just curious about it

[mbonnin]

Filed https://github.com/graphql/graphql-scalars/issues/23

[mbonnin]

Is there an exhaustive list somewhere for all such scalars?

The list is (in small) on top of https://scalars.graphql.org/. Right now it's only LocalDate and DateTime

[Stylianos Gakis]

Hmm, I meant a list which would also probably include the Upload scalar, and any other such scalars that exist too.

[mbonnin]

https://scalars.graphql.org/ is the only "official" one. Community has a ton of custom scalars, sometimes with different coercing rules, there could be some lists but most probably opinionated

[Stylianos Gakis]

https://spec.graphql.org/October2021/#sec-Scalars Upload isn’t here? 👀
I must be completely misunderstanding smth here

[mbonnin]

Upload has never been specified

[Stylianos Gakis]

Is Upload just something that you give us in apollo-kotlin for convenience then?

[mbonnin]

It's a de-facto standard but not an official one

[mbonnin]

Is Upload just something that you give us in apollo-kotlin for convenience then?

Actually I don't think apollo-kotlin comes with Upload

[mbonnin]

It requires you to map your existing Upload scalar

[mbonnin]

But your backend could name it FileUpload or FooBar you could still use the apollo-kotlin upload support with mapScalarToUpload("FooBar")

[Stylianos Gakis]

Right right, but you give us convenience functions to do work with it, like fun Path.toUpload(contentType: String, fileSystem: FileSystem = systemFileSystem): Upload and so on

[mbonnin]

Upload is a kotlin type here

[mbonnin]

You can map FooBar to com.apollographql.apollo3.api.Upload if you want

[Stylianos Gakis]

Yeah, and we need to map it in the gradle config mapScalarToUpload("Upload") and we then work with it. And the names being the same in our setup, since we just went with the same name made me forget that we had to do this mapping. It’s been there since forever and I remember that it was very easy to setup so in my mind I thought it’s just a normal built-in scalar.
I had the wrong impression about all this here, thanks a lot for clearing it all up for me!

[mbonnin]

Sure thing!

[mbonnin]

I wish it was in the spec!

[mbonnin]

Upload , Json , different Dates , Long

[mbonnin]

That would cover like 90% of the case I think