Support for custom scalars

[Poincare]

After speaking with @glasser, I noticed that we don't currently have great support for custom scalar types on Apollo Client. I understand that these are probably pretty difficult to support without having the schema on the client but we could make it possible to add some custom support for scalar serialization on the client.

Although custom scalar types are certainly important for lots of applications, considering some of the other features and fixes we have to build, this is probably not hugely important at the moment. (I could definitely be wrong on this.)

[glasser]

I suspect it would be easier if my app was using the current version of react-apollo which makes it easier to transform data between the GraphQL query and the React props. But of course, it would be even easier if you could just say "any Date is a Date"...

[stubailo]

I think having a "standard" set of custom scalars, like Date, would be a great way to solve this.

[rricard]

Why not provide a way to handle those at network layer level ? I will try something in this domain soon with file uploads, I'll let you know what I find!

[Akryum]

We could have some sort of type manager that is in charge of de-serializing scalars on the client, with some handy defaults like Date, while still being extendable.

Hi folks,

I'm working on a patch which adds a CustomScalarManager class with the following features :

• built-in types (which you can use or not, depending on your needs)
• user-defined types
• you can register a type after instanciation
• you can also un-register types
• chainable methods

I have a the following questions :

1. Which built-in types would you consider worth implementing ? At the moment I have Date and Json.
2. How should this CustomScalarManager class be 'plugged' with the existing code ? Following @rricard's comment I was thinking of implementing a CustomScalarManager.getAfterWare() method. And let the user make a networkInterface.useAfter(customScalarManagerAfterWare). The afterware would de-serialize scalars. This is not implemented yet in my patch. Am I going in the right direction or am I mistaking somewhere ?

I'm trying to gather a few comments in order to make a great patch. Then I'll do a PR and ask for reviews.

If there are other features which look interesting to you for that CustomScalarManager, just ask and I'll try to include them in my patch.

Regards,
Olivier

[dchambers]

Hi @oricordeau, I've just come across this issue, and what you're suggesting seems to be what I need given that I've configured Apollo GraphQL Server to support a Date scalar. Did you make any progress here, or have you discovered some other way of doing this?

[SachaG]

I'm interested in this too. For now, I've hacked my way around this limitation by manually converting any field that's supposed to be a date into an actual Date object in my query containers, but it'd be a lot cleaner if dates could be stored as dates directly in the store.

[Akryum]

@stubailo I'm curious to know how did you solved this in Optics when you have to fetch data with dates?

[calebmer]

Not sure if this has been mentioned already, but if we want to support custom scalars we would need the GraphQL schema to know which fields correspond to which scalar types. How about adding support like this?

gql`
  fragment on User {
    joinedAt @transform(${joinedAt => new Date(joinedAt)})
  }
`

Now whatever code is using that fragment has access to a transformed scalar and we don’t need to fetch the schema. I think this function-in-directive pattern is a super powerful tool to start looking into. For example we could also use it to allow users to define resolvers for client fields:

gql`
  fragment on User {
    localSettings @client(${() => { ... }})
  }
`

[Akryum]

@stubailo I was wondering if the team have any design ideas you could share to tackle this?

[helfer]

@Akryum I'll ask @daniman from the service team what they did and report back to you.