defaultFieldResolver does not resolve field alias

[alvis]

Currently defaultFieldResolver is used in graphql-tools as the default resolver. However, it doesn't work with aliased field. e.g. The first example works but not the second one. In the second case, nickname would be resolved to null rather than being identical to name.

query {
  me {
    name
  }
}

query {
  me {
    nickname: name
  }
}

The cause of the issue is that the current resolver only takes the fieldName from info rather than any aliased name in line 1232.

graphql-js/src/execution/execute.js

Lines 1224 to 1238 in ef585e9

	export const defaultFieldResolver: GraphQLFieldResolver<any, *> = function(
	source,
	args,
	contextValue,
	info,
	) {
	// ensure source is a value for which property access is acceptable.
	if (typeof source === 'object' || typeof source === 'function') {
	const property = source[info.fieldName];
	if (typeof property === 'function') {
	return source[info.fieldName](args, contextValue, info);
	}
	return property;
	}
	};

This issue is also related to ardatan/graphql-tools#519, which leads to a custom solution (doc) in https://github.com/apollographql/graphql-tools/blob/v3.0.0/src/stitching/defaultMergedResolver.ts

I believe that we should fix this at the root. Changing info.fieldName to info.path.key or info.fieldNodes[0].alias.value seems to be non-breaking and yet a proper fix for supporting field alias. If agreed, I'd like to make a PR for that.

@robinhood: Do you have any opinion on the change?

[IvanGoncharov]

@alvis It works exactly as expected. If we use aliases, you can't return objects from your resolver. For example, in your query, your resolver can't return { name: 'IvanGoncharov' } anymore.

Also note that current behavior is design to support wrapping your resolvers in classes, see here: https://graphql.org/graphql-js/object-types/

So using aliases make sense only for proxying request but absolute majority of users use this library to execute requests so library optimized for this use cases. The solution used Apollo totally makes sense in this case.

[alvis]

@IvanGoncharov Thanks for explaining.

I'm trying to understand this. You said the resolver can't return { name: 'IvanGoncharov' } in my example if I use info.path.key instead of info.fieldName. Do you mean that info.path.key and info.fieldNameare different if there's no alias? Becoz what I observe is that they're always identical for ordinary call, except the case of alias.

[IvanGoncharov]

@alvis Let's make a concrete example, I will use graphql-tools wrapper since it more familiar to you:

const typeDefs = `
  type User {
    name: String
  }

  type Query {
    me: User
  }
`;

const resolvers = {
  Query: {
    me() {
      return { name: 'Ivan' };
    }
  }
}

export const schema = makeExecutableSchema({
  typeDefs,
  resolvers,
});

Let's apply proposed change and call this query:

{ 
  me {
    name
  }
}

Everything is good and you will get:

{
  "data": {
    "me": {
      "name": "Ivan"
    }
  }
}

Let's send:

{ 
  me {
    firstName: name
  }
}

Since graphql will look for firstName instead of name you will get:

{
  "data": {
    "me": {
      "firstName": null
    }
  }
}

[alvis]

@IvanGoncharov Yes. It's a good example.

My question is: aren't we suppose to get

{
  "data": {
    "me": {
      "firstName": "Ivan"
    }
  }
}

since firstName is an alias of name? This is the reason I open this issue.

May be I'm wrong, but as far as in my expereince with Prisma, obj received in resolve(obj, args, ctx, info) becomes

{ "firstName": "Ivan" }

in the 2nd example. That's why I thought using info.path.key is a better idea.

[IvanGoncharov]

@alvis I'm confused, so let's go step by step based on my example:

1. Resolver called for me field it returns { name: 'Ivan' } and this value becomes source.
2. name doesn't have resolver so defaultFieldResolver is called with args:

• source - { name: 'Ivan' }
• info - where fieldName is name but info.path.key is firstName.

3. Here is where current and proposed behavior differs:

• Current: const property = source[info.fieldName]; so property became Ivan.
• Proposed: const property = source[info.path.key]; so property became undefined.

4. defaultFieldResolver resolver returns property and it becomes value in the responce.

[IvanGoncharov]

May be I'm wrong, but as far as in my experience with Prisma , obj received in resolve(obj, args, ctx, info) becomes

Ok, I think I understand now. You are right because Prisma is a proxy, but as I wrote previously:

So using aliases instead of field names make sense only for proxying request but absolute majority of users use this library to execute requests so library optimized for this use case.

[alvis]

Thanks for explaining. It's clear to me now.

[IvanGoncharov]

Thanks for explaining. It's clear to me now.

@alvis Great to hear! Proxying GraphQL requests are a pretty new field, so not everything works as expected. For example, you can break the majority of proxies with a query like that:

{
  interfaceOrUnion {
    __typename: someField
  }
}

And it's not a graphql-js or GraphQL specification problem it just one more case that proxy needs to handle.

[alvis]

@IvanGoncharov Great to see some clear examples and a thorough explanation here. I think it helps people like me who do not know the difference and have no clue why things are not behaving as expected.

[sneharam7]

Hi,
I need help in binding data in graphql due to field name mismatch.

This is my type defined in schema.
type sc{
cnt_nmbr: String!
}
type Query {
scresponse: [sc]
}
But the api response that i am trying to bind:

{ "Services.row": [
{
"Services.cnt_nmbr": "1-206980667125"
}
]}

I understand that api response "Services.cnt_nmbr" is not equal to cnt_nmbr and hence data binding is failing. How will i resolve this?