Skip to content
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

Feature: Allow overriding built-in scalar types #917

Closed
stubailo opened this issue Jun 16, 2017 · 7 comments
Closed

Feature: Allow overriding built-in scalar types #917

stubailo opened this issue Jun 16, 2017 · 7 comments

Comments

@stubailo
Copy link

Specifically, sometimes we want to replace ID with something like this that can handle Mongo ObjectIDs: https://github.com/tmeasday/create-graphql-server/blob/79abbd67f4aef3b44fb8605e41eb2ba7978810a6/skel/resolvers/index.js#L8

I think it could be as simple as just allowing the schema to take a type called ID and just using that instead of the built-in.

@OlegIlyenko
Copy link
Contributor

Had also similar requirements in quite a few places (but most importantly with IDs, which we represent internally as UUIDs). Though I implemented it with scalar aliases.

Just replacing a built-in scalar can be quite limiting since the schema can have different types of IDs

@leebyron
Copy link
Contributor

This is pretty interesting. I think providing custom scalar types with the same name as the built-in types might break some core assumptions in the codebase that check for these built-ins. If taking that approach, look out for this. Allowing custom serialization behavior for these types could be pretty sweet. I would love to see a PR which added this in a nice way.

@alexmcmillan

This comment has been minimized.

@IvanGoncharov

This comment has been minimized.

@ghirlekar
Copy link

I have another use-case that would greatly benefit from this.

I want to override the serialization/deserialization of the String type to convert all Windows-style line endings to Unix-style for incoming/outgoing data. Some of my clients use Windows machines and some use Unix, and my database also has both style of line endings.

Overriding the String serialization/deserialization is a single point of change instead of all the different places I would need to add code to strip carriage returns.

Is there any plan to add this feature to an upcoming release?

@IvanGoncharov
Copy link
Member

The problem here is that introspection depends on built-in scalars.
For example, if you override string to change line ending it will also affect string returned from introspection.
Even for scalars like ID that currently don't use by introspection can be used in future spec releases.
I think the correct solution would be to create custom scalars based on standard types (e.g. scalar UUID as String) which is proposed in graphql/graphql-spec#521 and attach validation/parsing/serialization to this scalar.

@CristianPi
Copy link

any workaround? casting and validation for ID?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants