Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to get Proto object from the parent arguments? #91

Open
IvBre opened this issue Oct 30, 2019 · 3 comments
Open

How to get Proto object from the parent arguments? #91

IvBre opened this issue Oct 30, 2019 · 3 comments

Comments

@IvBre
Copy link

IvBre commented Oct 30, 2019

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 ❤️

@IvBre
Copy link
Author

IvBre commented Oct 31, 2019

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.

@sheepdreamofandroids
Copy link
Contributor

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...

@IvBre
Copy link
Author

IvBre commented Nov 4, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants