You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the things that can be achieved with Json parsers like Moshi is writing custom adapters to map some types to the non-default ones.
This issue is to investigate adding the same kind of things for the generated models. Because there is a schema and models do not map the schema types directly but the requests fields in the query it's more difficult to do so but something might be done for simple case like for an example typesafe ids.
Let's say you have a kotlin class for a user id
// A small wrapper to make sure we don't pass a wrong id to a function expecting a user iddata classUserId(valid:String)
We could allow through schema extensions to override the type of User.id in the schema:
# extra.graphqlsextendtypeUser {
# this is not valid GraphQL but we could support it (or find another way using directives maybe)id: UserId
}
scalarUserId
Then mapping userIds could be done like any other custom scalars. Looks like that could help for simple cases. Compound types are going to be more complicated to handled at first sight but might also benefit from something like this.
The text was updated successfully, but these errors were encountered:
This can be achieved by changing in the schema the type of a field to a custom scalar, and write an adapter for it. But touching the schema on the client side is not ideal, as changes can be overridden when fetching the latest schema. This can be mitigated by a Gradle task that manipulates the schema automatically before the codegen is invoked.
Fetching the latest schema wouldn't necessarily override the changes if they're defined separately in an extras.graphqls file right? Though it does introduce a risk of breaking changes if the schema deviates from what it was before. But then again the generated Kotlin code has the same risk with any code that's written against it
This same mapping could be used in subsequent runs of the task to ensure that the initial schema type hasn't changed and the transformation is still valid.
One of the things that can be achieved with Json parsers like Moshi is writing custom adapters to map some types to the non-default ones.
This issue is to investigate adding the same kind of things for the generated models. Because there is a schema and models do not map the schema types directly but the requests fields in the query it's more difficult to do so but something might be done for simple case like for an example typesafe ids.
Let's say you have a kotlin class for a user id
We could allow through schema extensions to override the type of
User.id
in the schema:Then mapping userIds could be done like any other custom scalars. Looks like that could help for simple cases. Compound types are going to be more complicated to handled at first sight but might also benefit from something like this.
The text was updated successfully, but these errors were encountered: