auritylab/graphql-kotlin-toolkit

GraphQL toolkit for Kotlin.

graphql-kotlin-toolkit's Issues

Usage of existing enums

Sometimes there are already existing enums for the ones used in the GraphQL schema.
The code generator will currently always generate a new enum, which matches the one defined in the schema.

This behavior sometimes results in unnecessarily ugly code, therefore there should be an easier way to do that.

Possible fixes:

• Allow kRepresentation on Enums to directly use the existing enum.
  • Is there a way to guarantee that the given enum contains the required values? (Would break type safety and runtime otherwise)

Specify type for scalar "ID" explicitly (with converter)

There should be the possibility to set an explicit type for the "ID" scalar. This functionality should also come with a convert, as the ID is typically given as a String.

This may be implemented like this:

• Two new properties within the CodegenOptions. (Reference to the ID type and the converter implementation)
• Special handling for the ID scalar within the TypeMapper.
• Generate a converter interface.

Potential problem: Given resolver "User.emailAddress" and "UserEmail.Address" would clash

If there are two resolvers, say "User.emailAddress" and "UserEmail.address", there would be a clash, because the code generator would output "UserEmailAddress" for "User.emailAddress" and "UserEmailAddress" for "UserEmail.address".

Clear output directory before generating new files

There should be the functionality to (optionally) clear the output directly before generating new files.

Buildscript refactoring

The buildscript (gradle) of the whole project shall be refactored and simplified.

Pagination field resolvers: Support for own types and validation

The current implementation of the pagination field resolvers requires the return type of a field to be a list (e.g. [User]). But the generator should also support own *Connection and *Edge types.
When bringing in their own types, the generator should validate them against the GraphQL Cursor Connections Specification.

The user should also be able to define additional fields on the *Connection and *Edge types. When additional fields are given the generator has to generate specific Kotlin classes to support those. (Currently, global Kotlin classes are being used (PaginationConnectionGenerator, PaginationEdgeGenerator))

The pagination field resolvers should also properly handle the nullability of the types.