[GraphQL] Use same type for mutations and queries if normalization context is equal

[javajan]

Description

https://api-platform.com/docs/core/graphql/#different-types-when-using-different-serialization-groups

In your documentation it states that if the normalization context is the same, then the generated type will be equal. However, looking at the TypeBuilder's code this appears to only be the case for collection_query and item_query. It would be nice if this was also the case for mutations and even custom mutations, because otherwise certain features of popular clients like Apollo don't work as expected (e.g. caching).

[alanpoulain]

Where do you see that it is not the case?

[javajan]

core/src/GraphQl/Type/TypeBuilder.php

Lines 70 to 81 in 94863cd

	if (('item_query' === $queryName || 'collection_query' === $queryName)
	&& $resourceMetadata->getGraphqlAttribute('item_query', 'normalization_context', [], true) !== $resourceMetadata->getGraphqlAttribute('collection_query', 'normalization_context', [], true)) {
	if ('item_query' === $queryName) {
	$shortName .= 'Item';
	}
	if ('collection_query' === $queryName) {
	$shortName .= 'Collection';
	}
	}
	if ($wrapped && (null !== $mutationName || null !== $subscriptionName)) {
	$shortName .= 'Data';
	}

Not certain, but it looks like for item_query and collection_query the normalization context is compared, but not for mutations. The issue seems to lie in line 79: Data is always added to the name no matter the normalization context.

Heres a quick example illustrating what I mean:

App\Entity\Conversation\ConversationMessage:
  graphql:
    item_query:
      normalization_context:
        groups: [ 'conversation:read', 'user:read' ]

    createText:
      mutation: App\Resolver\Conversation\CreateTextMessageResolver
      args:
        text:
          type: String!
      normalization_context:
        groups: [ 'conversation:read', 'user:read' ]

type Query {
    conversationMessage(id: ID!): ConversationMessage
}

type Mutation {
    createTextConversationMessage(input: createTextConversationMessageInput!): createTextConversationMessagePayload
}

type ConversationMessage implements Node {
  id: ID!
  text: String!
}

type createTextConversationMessagePayload {
  conversationMessage: createTextConversationMessagePayloadData
  clientMutationId: String
}

type createTextConversationMessagePayloadData implements Node {
  id: ID!
  text: String!
}

In my opinion createTextConversationMessagePayloadData is not needed as it is the same as ConversationMessage, because the context is the same.