Add additional types to the schema

[de55]

I'd like to be able to make it so that Collection<T> is treated equivalently to List<T>. Is there any possible way to do that now with the hooks? And if not, would we be able to make this piece configurable:

internal fun KClass<*>.isListType(): Boolean = this.isSubclassOf(List::class) || this.java.isArray

[de55]

On a related note, I think this would be possible with the hooks if there was a way to add extra types to be generated. Is that something you would be open to adding (or that already exists)? The issue right now is that if I were to add Collection::class to

override fun willGenerateGraphQLType(type: KType): GraphQLType? 

then I have to make sure that <T> exists, which I don't think I can do if the only place it is added to the schema is as Collection<T>

[de55]

On a related note, I think this would be possible with the hooks if there was a way to add extra types to be generated. Is that something you would be open to adding (or that already exists)? The issue right now is that if I were to add Collection::class to

override fun willGenerateGraphQLType(type: KType): GraphQLType? 

then I have to make sure that <T> exists, which I don't think I can do if the only place it is added to the schema is as Collection<T>

I confirmed that I would be able to accomplish what I am trying to if I could add a list of additional
types to be generated. That is because I could then do this:

    override fun willGenerateGraphQLType(type: KType): GraphQLType? = when (type.classifier) {
        Collection::class -> GraphQLList.list(GraphQLTypeReference.typeRef(type.getTypeOfFirstArgument().getSimpleName()))
        else -> super.willGenerateGraphQLType(type)
    }
    override fun isValidSuperclass(kClass: KClass<*>): Boolean {
        return if(kClass == Collection::class) false else  super.isValidSuperclass(kClass)
    }

That code works for sets/collections/etc. right now, as long as the underlying object within the collection will eventually be built.

[dariuszkuc]

See #201

TLDR reason we only support list is due to deserialization issues, i.e. it is not possible to enforce set properties in JSON.

[de55]

I understand why you don't broadly support it, but I'd still rather set it up in the hooks. I also have other reasons that I'd like to add types, like adding extension functions. I had the extension functions working, but some of the 2.0 changes broke my current implementation.

The change to be able to add additional types would be simple see #585.

[de55]

Closed by #593