feature: Use class name by default for `@DgsDataLoader#name`, and add some inline methods to `DgsDataFetchingEnvironment`
~~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.
@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>>()
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.
This is merged in https://github.com/Netflix/dgs-framework/pull/904 correct? Or is there more to it?
Can this issue be closed?
Appears to have been solved by #904.
It has indeed, I forgot to reply to Paul, thanks