Closed TizianoCoroneo closed 5 months ago
Hey @TizianoCoroneo! I thought I was going to have to say no to this request (because ID is reserved as a specific type in the GraphQL Spec), but after reviewing the spec, it just says that ID must be serialized to a String
. So I think this is totally acceptable!
@calvincestari @BobaFetters do you see any reason why we shouldn't allow this?
If you want to make a PR for this, I think we can accept it!
We can't allow complete customization of the type since it will still need to be bound by the serializable-to-string requirement in the GraphQL spec. I don't know exactly how this would work yet but it'd need to conform to ExpressibleByStringLiteral
and CustomStringConvertible
, or something like that. There is also a ton of helper extensions that we've got on the basic scalar types already that String
benefits from, so it could be complicated to untangle.
Happy to work with you in figuring this out though @TizianoCoroneo.
We can't allow complete customization of the type since it will still need to be bound by the serializable-to-string requirement in the GraphQL spec.
I'm not sure how much that matters? Client devs are going to implement their custom scalars to consume the scalar specified by their schema. If your schema is trying to use the ID
type as something that isn't serializable to a String
, your server itself isn't spec-compliant. But honestly, in that case, is there any value in apollo-ios
refusing to work?
There is also a ton of helper extensions that we've got on the basic scalar types already that
String
benefits from, so it could be complicated to untangle.
I'm not sure if any of these are relevant. ID
really does function just as any other custom scalar would. If your ID
scalar is just a String
, then you're good to go. If not, this proposal would allow you to implement the CustomScalarType
protocol and then you would get all the required functionality that a Custom Scalar needs to work.
Maybe I'm missing something, but if so, I think we need to be more clear on what specifically would go wrong with this. I can't actually come up with a situation in which this would be problematic.
@TizianoCoroneo, we aren't going to allocate time to implement this ourselves in the near future, but if it's something you want, please go ahead and try it out. If you get it working in your project and that doesn't reveal any problems that we had missed, we'll do a little more thinking and investigation, but I'm hoping it should be mergeable.
Implemented in #363. Should be included in next release!
Hey 👋 I had a half baked implementation of this, but you were quicker 😂 Thanks for the fast response!
Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo iOS usage and allow us to serve you better.
Use case
I'd like to be able to customize the backing type of the
ID
of the codegen-generated models.In our API we have IDs that are encoded representations of other things (can't go in too much details), so I would like to have my own custom
String
-wrapper type with additional functionality, instead of the mandatedString
as the type behind theID
typealias. Today I have to extendString
, polluting the namespace instead.Example: the
SchemaMetadata.graphl.swift
contains this code:Describe the solution you'd like
It would be nice to have it as another custom scalar instead: