Allow additional types to be added with custom SchemaGenerator #587
Conversation
This is a patch change to allow additional types to more easily be extended in later PRs. As a side-effect of this change we actually simplify where types are all generated and the main generateSchema function becomes just a little more straight forward
smyrick
added
changes: patch
There was a problem hiding this comment.
Looks good but I'm wondering whether there should be an easier way to add the additional types, i.e. it still looks like you kind of have to hack it through to add them in. Should we add something akin to what was done for federation and addAdditionalTypesWithAnnotation?
|
I am not adding that functionality in this PR. That will be done in #585 As seen there, having a way to dynamically update the |
|
I was thinking more along the lines of exposing the functionality so one could extend the |
After we have fully generated queries,mutations, and subscriptions there are no more type references. We only have this issue when we were adding classes in the middle of generate so this actually reduces logic and branches in the library
smyrick
changed the title
|
@dariuszkuc I updated the PR. Now the method |
...otlin-schema-generator/src/main/kotlin/com/expediagroup/graphql/generator/SchemaGenerator.kt
Outdated
Show resolved
Hide resolved
...otlin-schema-generator/src/main/kotlin/com/expediagroup/graphql/generator/SchemaGenerator.kt
Outdated
Show resolved
Hide resolved
...otlin-schema-generator/src/main/kotlin/com/expediagroup/graphql/generator/SchemaGenerator.kt
Outdated
Show resolved
Hide resolved
Do not make the function open for outside calling right now. Discussing further with team and we can add the new feature in a separate PR
|
I have undone making the new method open for calling in protected scope and instead just made it private. We are still discussing on the team if we do actually want developers to use this custom behaviour or are we going against GraphQL best practices. If we wanted to open it to protected scope later that is a simple PR. |
|
|
||
| return generator.config.hooks.willAddGraphQLTypeToSchema(type, graphQLType) |
There was a problem hiding this comment.
We do not want to call the hook with type references. This is now required for the new format
As dicussed in other PRs ExpediaGroup#587 and ExpediaGroup#585 we can allow developers to have more customization of the schema by allowing them to add additional types of their own without having to add it to the schema directly. What they do with this feature will be up to them, but from a libray perspective it is not bad feature to support.
* Allow updating custom additional types As dicussed in other PRs #587 and #585 we can allow developers to have more customization of the schema by allowing them to add additional types of their own without having to add it to the schema directly. What they do with this feature will be up to them, but from a libray perspective it is not bad feature to support. * Make function open
…iaGroup#587) * Refactor additional types This is a patch change to allow additional types to more easily be extended in later PRs. As a side-effect of this change we actually simplify where types are all generated and the main generateSchema function becomes just a little more straight forward * Add more unit tests * Simplify generateAdditionalTypes logic After we have fully generated queries,mutations, and subscriptions there are no more type references. We only have this issue when we were adding classes in the middle of generate so this actually reduces logic and branches in the library * Remove new features for now Do not make the function open for outside calling right now. Discussing further with team and we can add the new feature in a separate PR
* Allow updating custom additional types As dicussed in other PRs ExpediaGroup#587 and ExpediaGroup#585 we can allow developers to have more customization of the schema by allowing them to add additional types of their own without having to add it to the schema directly. What they do with this feature will be up to them, but from a libray perspective it is not bad feature to support. * Make function open
📝 Description
This is a patch change to allow additional types to more easily be extended in later PRs. As a side-effect of this change we actually simplify where types are all generated and the main generateSchema function becomes just a little more straight forward.
🔗 Related Issues
This will make #585 a little eaiser to implement