阿波罗服务器：向嵌套解析器传递参数[英] Apollo Server: pass arguments to nested resolvers

问题描述

My GraphQL query looks like this:

{
    p1: property(someArgs: "some_value") {
        id
        nestedField {
            id
            moreNestedField {
                id
            }
        }
    }
}

On the server side, I'm using Apollo Server. I have a resolver for the property and other resolvers for nestedField and moreNestedField. I need to retrieve the value of someArgs on my nested resolvers. I tried to do this using the context available on the resolver:

property: (_, {someArgs}, ctx) => {
    ctx.someArgs = someArgs;

    // Do something
}

But this won't work as the context is shared among all resolvers, thus if I have multiple propertyon my query, the context value won't be good.

I also tried to use the path available on info on my nested resolvers. I'm able to go up to the property field but I don't have the arguments here...

I also tried to add some data on info but it's not shared on nested resolvers.

Adding arguments on all resolvers is not an option as it would make query very bloated and cumbersome to write, I don't want that.

Any thoughts?

Thanks!

推荐答案

Params can be passed down to child resolvers using the currently returned value. Additional data will be removed from the response later.

I'll 'borrow' Daniel's code, but without specific params - pass args down as reference (suitable/cleaner/more readable for more args):

function propertyResolver (parent, args) {
  const property = await getProperty()
  property.propertyArgs = args
  return property
}

// if this level args required in deeper resolvers
function nestedPropertyResolver (parent, args) {
  const nestedProperty = await getNestedProperty()
  nestedProperty.propertyArgs = parent.propertyArgs
  nestedProperty.nestedPropertyArgs = args
  return nestedProperty
}

function moreNestedPropertyResolver (parent) {
  // do something with parent.propertyArgs.someArgs
}

As Daniels stated this method has limited functionality. You can chain results and make something conditionally in child resolver. You'll have parent and filtered children ... not filtered parent using child condition (like in SQL ... WHERE ... AND ... AND ... on joined tables), this can be done in parent resolver.

其他推荐答案

Please check this answer here on how to pass the arguments: https://stackoverflow.com/a/63300135/11497165

To simplify it, you can define your field type with args:

In your Type Definition

type Query{
  getCar(color: String): Car
  ... other queries
}

type Car{
  door(color: String): Door // <-- added args
  id: ID
  previousOwner(offset: Int, limit: Int): Owner // <-- added args
  ...
}

then, in your client query (from apollo client or your gql query):

query getCar(carId:'123'){
  door(color:'grey') // <-- add variable
  id
  previousOwner(offset: 3) // <-- added variable
  ... other queries
}

You should be able to access color in your child resolver arguments:

In your resolver:

Car{
  door(root,args,context){
   const color = args.color // <-- access your arguments here
  }
  previousOwner(root,args,context){
   const offset = args.offset // <-- access your arguments here
   const limit = args.limit // <-- access your arguments here
  }
  ...others
}

For your example:

it will be like this

{
    p1: property(someArgs: "some_value") { // <-- added variable
        id
        nestedField(someArgs: "some_value") { // <-- added variable
            id
            moreNestedField(offset: 5) {
                id
            }
        }
    }
}

其他推荐答案

You can pass the value through the parent field like this:

function propertyResolver (parent, { someArgs }) {
  const property = await getProperty()
  property.someArgs = someArgs
  return property
}

function nestedPropertyResolver ({ someArgs }) {
  const nestedProperty = await getNestedProperty()
  nestedProperty.someArgs = someArgs
  return nestedProperty
}

function moreNestedPropertyResolver ({ someArgs }) {
  // do something with someArgs
}

Note that while this works, it may also point to an underlying issue with your schema design in the first place. Depending on how you're resolving these fields (getting them from a database, making requests to another API, etc.), it may be preferable to take a different approach altogether -- for example, by eager loading everything inside the root resolver. Without more context, though, it's hard to make any additional recommendations.