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

[Brainstorming] customize generated Kotlin models #3958

Closed
martinbonnin opened this issue Mar 24, 2022 · 3 comments
Closed

[Brainstorming] customize generated Kotlin models #3958

martinbonnin opened this issue Mar 24, 2022 · 3 comments

Comments

@martinbonnin
Copy link
Contributor

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 id
data class UserId(val id: String)

We could allow through schema extensions to override the type of User.id in the schema:

# extra.graphqls
extend type User {
  # this is not valid GraphQL but we could support it (or find another way using directives maybe)
  id: UserId
}

scalar UserId

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.

@BoD
Copy link
Contributor

BoD commented Jun 14, 2024

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.

@BoD BoD closed this as not planned Won't fix, can't repro, duplicate, stale Jun 14, 2024
@sampengilly
Copy link

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

@martinbonnin
Copy link
Contributor Author

@sampengilly the "schemaTransformation" Gradle task could generate an additional artifact containing the type remapping.

For an example, if we're saying we want to introduce a custom scalar for product ids called ProductID, the Gradle task could generate the mapping:

{
  "Product.id": {
    "from": "ID!"
    "to": "ProductID"
  }
}

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.

Hope this helps?

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

3 participants