dgs-framework icon indicating copy to clipboard operation
dgs-framework copied to clipboard

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

Open jord1e opened this issue 3 years ago • 3 comments

~~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: afbeelding

correct: afbeelding

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: afbeelding

Contributing

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

jord1e avatar Feb 05 '22 16:02 jord1e

@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>>()

srinivasankavitha avatar Feb 06 '22 23:02 srinivasankavitha

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.

jord1e avatar Mar 03 '22 22:03 jord1e

This is merged in https://github.com/Netflix/dgs-framework/pull/904 correct? Or is there more to it?

Can this issue be closed?

paulbakker avatar May 02 '22 23:05 paulbakker

Appears to have been solved by #904.

Emily avatar Dec 07 '23 21:12 Emily

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

jord1e avatar Dec 07 '23 21:12 jord1e