-
-
Notifications
You must be signed in to change notification settings - Fork 676
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
Support for __typename #181
Comments
First of all, thanks @19majkel94 for adding this to your to-do list, it's a much-needed feature for our team. :) Just chiming in to vocalise my support for both of the options you suggested: being able to set the |
@19majkel94 Until this new feature arrives: how would I provide the type in the current version? From your initial comment I would assume, that TypeGraphQL can do this somehow magically by itself, but I get the error
I don't understand this. Are you referring to the inner workings of TypeGraphQL or does my implementation need to provide a property or something in the class? What do I need to do, that |
// where interfaces or unions are returned.
@Query(returns => MyInterface)
myInterface() {
// use class instances
const response = new MyObjectType();
response.sampleField = "sampleFieldValue";
return response;
} |
@19majkel94 any estimation of implementation? I tried to use your alternative without success
Here is my resolver (using nestjs):
I still get Actually what would be super cool is to be able to do:
|
That's a great idea, you can reuse the property data instead of forcing to use spread operator and
Nest has it's own runtime for resolving types and other things - TypeGraphQL is used only for SDL generation and nothing else. |
Right now, for interfaces and unions, TypeGraphQL determines the type of the returned value using
foo instanceof Foo
. This force to use class instances in every case where interfaces or unions are returned.But this might be problematic in some cases, so it could just fallback to the
__typename
based detection for the easier cooperation with plain objects.Side note
Also
resolveType
implementation in unions could be omitted as:Or maybe even better, for better compatibility, it should allow providing own
resolveType
function in interface and union decorators/creators.The text was updated successfully, but these errors were encountered: