-
Notifications
You must be signed in to change notification settings - Fork 2k
Feature Request: Allow interfaces to resolve to other interfaces #3253
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
Comments
I think i have a similar issue so i add here my case : Suppose I have the following schema:
I can't use interface in union even i have a
and can't use |
@gwenker => I think your comments are unrelated to a resolveType hiearchy, but is related to discussion at graphql/graphql-spec#711 |
= The child interfaces must eventually resolve to a runtime object type. = Interface cycles raise a runtime error. implements: graphql#3253
= The child interfaces must eventually resolve to a runtime object type. = Interface cycles raise a runtime error. implements: graphql#3253
= The child interfaces must eventually resolve to a runtime object type. = Interface cycles raise a runtime error. implements: graphql#3253
= The child interfaces must eventually resolve to a runtime object type. = Interface cycles raise a runtime error. implements: graphql#3253
This formalizes the proprosed feature within `graphql-js` whereby the internal method provided by JavaScript for runtime type resolution is allowed to return an intermediate interface. See: Issue: graphql/graphql-js#3253 PR: graphql/graphql-js#3599 @IvanGoncharov [suggested](graphql/graphql-js#3599 (review)) that this would require a spec change. Alternatively, perhaps the recursion [should be considered to be a feature of the internal system](graphql/graphql-js#3599 (comment)) itself, possibly limited to JavaScript-like implementations. This PR provides some potential spec text, were a spec change to be considered necessary.
This is doable in user land, but if graphql/graphql-spec#960 or something like it lands, we should implement it within the reference implementation. Until then, closing this issue in the name of general clean up. |
I originally raised this in Apollo Server and was told that it's actually implemented here.
Suppose I have the following schema:
I'd like to set up my resolvers for Node and Product like so:
In the current implementation of graphql-js, the Node resolver will result in an error because it resolves to Product, an interface type. This is despite the fact that Prodcut goes on to resolve to a concrete type. To make this work, the developer has to add logic for resolving Food to both the Product and Node resolver. This introduces code duplication, which becomes worse as more implementations of Product are added, and especially if other interfaces that implement Node and have own implementations are introduced.
I propose that it would be easier for the developer to maintain their resolvers if resolution of interface types could be chained. For the Node resolver in the example, that would mean when it resolves to Product, it goes on to use Product's
__resolveType
to resolve to the concrete type Food.The text was updated successfully, but these errors were encountered: