rejoiner
rejoiner copied to clipboard
How to get Proto object from the parent arguments?
Hello, I can't seem to find a way how to access current field parent arguments, and getting the actual resolved Proto object. For example, we have this query:
query ($input: Input_proto_request_params) {
search(
input: $input
) {
item {
specificProperty {
value
}
}
}
}
Now, field specificProperty
is a SchemaModification
kind of field, and we need the $input: Input_proto_request_params
variable to be able to resolve it.
I found a way that by injecting DataFetchingEnvironment
in the method we could get the list of parent arguments, like:
dataFetchingEnvironment.executionStepInfo.parent.arguments
but with this, I get the LinkedHashMap
, not the converted to Proto class object. I could create the Proto object manually, but that means the same object is constructed two times.
Is there a way to get access to the parent argument, but the already resolved Proto object one?
Thank you
P.S. Love the library, thank you very much for this awesome product ❤️
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.
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...
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.