Allow to call resolveType outside of execute context

[DavidTkachenkoAstrumu]

Request

resolveType highly depends on the execute function context by requiring internal context: TContext and info: GraphQLResolveInfo params. It makes it impossible to use for one's own needs.

Could you please provide a public resolveType implementation which accepts server and request schema instead of execution context? Or suggest any alternative solution?

Why do I need it?

I am writing a graphQL plugin. I have no control over modifying the server or the request schema definition. However, I need to figure out which type object graphQL returns in response among all available types in the union type definition.

I need to know the type of objects as my plugin behavior should differ depending on which object I have received. And I want to use specifically resolveType instead of guessing type by schema to be aligned with server custom type resolution logic.

e.g. with union SearchResult = User | Post and plain object { title: "Is it user or post" } I need to figure out in runtime that I have exactly a "Post".

[JoviDeCroock]

Hey,

I am personally a bit on the ropes whether that would work out for several reasons, the resolveType is dependent on the users implementation, this means that that function could be relying on context or properties on the object that are later stripped out as they aren't queried by the request-document.

A more reliable way of finding out what types is returned between the client and server is by adding the __typename selection which in your example will amount to { title: "Is it user or post", __typename: "Post" }. A lot of GraphQL clients also add this selection and then remove it from the response object before returning it to the user.

Another alternative if you really don't want to touch the GraphQL client document would be to do something like heuristic fragment matching, on a union type as you suggest the request document will look like

... on User { name }
... on Post { title }

You can go over the selections of these fragments and see which ones match, this is a heuristic approximation but should generally work well if you have access to the server-side schema to know the difference between the interface and object definitions.