How to get Proto object from the parent arguments? about rejoiner HOT 3 OPEN

Seems like this is working, but I'm not sure if its ideal:
In the parent resolver return the DataFetcherResult instead of the actual result, together with localContext set with the data object you want to share down the tree line, in this example its the request argument.

@Query
fun foo(request: ProtoRequestParams): ProtoResult {
  return DataFetcherResult.newResult<ProtoResult>()
            .data(getData(request))
            .localContext(request)
            .build()
}

And then in the child field resolver:

@SchemaModification(addField = "specificProperty", onType = ProtoItem::class)
fun specificProperty(item: ProtoItem, dataFetchingEnvironment: DataFetchingEnvironment): CompletableFuture<List<ProtoSpecificProperty>>? {
  val argument = dataFetchingEnvironment.getLocalContext<ProtoRequestParams>()
  // use the argument to resolve this field
}

Note that this code examples are in Kotlin.

from rejoiner.

Hi

Maybe I'm misunderstanding but to me it feels wrong that the resolution of specificProperty would depend on anything other than the item that it is connected to.

Could it be that Input_proto_request_params contains some context info for your query that should be repeated as a parameter on specificProperty?

I'm trying to solve a similar problem myself a.t.m. I'm using a hierarchy of implicitly retrieved context, well known variables and explicit parameters to solve that but I'm not sure what is "the right way" here...

from rejoiner.

Hello,

Maybe I'm misunderstanding but to me it feels wrong that the resolution of specificProperty would depend on anything other than the item that it is connected to.

According to the GraphQL specs, this scenario should be possible. That a child inherits arguments from its parent.

Could it be that Input_proto_request_params contains some context info for your query that should be repeated as a parameter on specificProperty?

Exactly, specificProperty requires Input_proto_request_params as well as its parent.

I'm trying to solve a similar problem myself a.t.m. I'm using a hierarchy of implicitly retrieved context, well known variables and explicit parameters to solve that but I'm not sure what is "the right way" here...

I was also thinking to just add this requirement directly on the field, but then the client needs to duplicate this argument, which I would rather avoid. I've solved it by setting localContext, not sure if that's the right way to go though.

from rejoiner.