feature: Use class name by default for @DgsDataLoader#name, and add some inline methods to DgsDataFetchingEnvironment

[jord1e]

Please read our contributor guide before
creating an issue. Also consider discussing your idea on
the discussion forum first.

Describe the Feature Request

The the annotated class's name as the name field of the @DgsDataLoader annotation by default
When annotating methods use something like SimpleClassName.methodName

Describe Preferred Solution

Using

@DgsDataLoader
class PersonByIdDataLoader : MappedBatchLoader<String, Try<Person>>{
    override fun load(keys: Set<String>): CompletionStage<Map<String, Try<Person>>> {
        TODO("Not yet implemented")
    }
}

We can then do:

val dl = dfe.getDataLoader<String, Try<Person>>(PersonByIdDataLoader::class.java)
// or
val dl = dfe.getDataLoader<String, Try<Person>>("PersonByIdDataLoader")

We may also wish to add some extra (inline-reified) methods to DgsDataFetchingEnvironment, for example:

inline fun <K, V, reified T : MappedBatchLoader<K, V>> DgsDataFetchingEnvironment.getMappedBatchLoader(): DataLoader<K, V> {
    return this.getDataLoader(T::class.java)
}
inline fun <K, V, reified T : BatchLoader<K, V>> DgsDataFetchingEnvironment.getBatchLoader(): DataLoader<K, V> {
    return this.getDataLoader(T::class.java)
}

Which gives us compile-time type checking:
incorrect:

correct:

Describe Alternatives

For the annotation proposal: keep it as is

For the methods:

inline fun <K, V, reified T> DgsDataFetchingEnvironment.getDataLoader(): DataLoader<K, V> {
    return this.getDataLoader(T::class.java)
}

would work instead of 4 seperate functions, but this does not do any type checking, it merely avoids having to use ::class.java:

Contributing

Would be willing to contribute a PR, or two separate ones.

[srinivasankavitha]

@jord1e - What exactly is the issue? This should work fine in your case, no?

val dataloader1 = dfe.getDataLoader<String, Try<Person>>(PersonByIdDataLoader::class.java)

The above should anyway handle the case where the data loader is a mapped data loader. Why do you need the second one shown in your example, i.e.

val dataloader2 = dfe.getMappedDataLoader<String, Try<Person>>()

[jord1e]

What exactly is the issue? This should work fine in your case, no?

Yes, it works, but it does not perform type-checking at compile time. Adding these utility methods gives library consumers to implement compile-time type-checking.

In the first example PersonByIdDataLoader is a MappedBatchLoader<String, Try<Person>>.
Because I am calling getMappedBatchLoader<String, Person, PersonByIdDataLoader>() in the example, the two first types are checked against the PersonByIdDataLoader, because the class returns Try<Person> we get a compilation error.

This is handy for when a return type or dataloader generic parameters changes types.

The four methods will be supplementary to the existing getDataLoader method.

[paulbakker]

This is merged in #904 correct? Or is there more to it?

Can this issue be closed?

[Emily]

Appears to have been solved by #904.

[jord1e]

It has indeed, I forgot to reply to Paul, thanks