Rebase of "Schema scalar of type" #1173
Conversation
This proposes an additive change which allows custom scalars to be defined in terms of the built-in scalars. The motivation is for client-side code generators to understand how to map between the GraphQL type system and a native type system. As an example, a `URL` custom type may be defined in terms of the built-in scalar `String`. It could define additional serialization and parsing logic, however client tools can know to treat `URL` values as `String`. Presently, we do this by defining these mappings manually on the client, which is difficult to scale, or by giving up and making no assumptions of how the custom types serialize. Another real use case of giving client tools this information is GraphiQL: this change will allow GraphiQL to show more useful errors when a literal of an incorrect kind is provided to a custom scalar. Currently GraphiQL simply accepts all values. To accomplish this, this proposes adding the following: * A new property when defining `GraphQLScalarType` (`ofType`) which asserts that only built-in scalar types are provided. * A second type coercion to guarantee to a client that the serialized values match the `ofType`. * Delegating the `parseLiteral` and `parseValue` functions to those in `ofType` (this enables downstream validation / GraphiQL features) * Exposing `ofType` in the introspection system, and consuming that introspection in `buildClientSchema`. * Adding optional syntax to the SDL, and consuming that in `buildASTSchema` and `extendSchema` as well as in `schemaPrinter`. * Adding a case to `findBreakingChanges` which looks for a scalar's ofType changing.
|
Thanks for doing this! If you don't mind, I'm going to merge this back into the original PR just to keep tracking of the issue consistent. I'm excited you're interested in this and are helping to champion it! I think now that the SDL is close to complete we can address this next |
@leebyron This was my original intention 👍
Meanwhile, I can work on adding a few more tests as a separate PR against |
|
I just updated that PR, so I'll close this - feel free to submit PRs against that branch with improvements and new tests. I think tests will be the most helpful, that will help highlight any remaining issues. |
As we discuss during WG I'm very interested in this feature and willing to be champion for it.
As the first step, I rebased #914