Is there an existing issue that is already proposing this?
Is your feature request related to a problem? Please describe it
Many people over many years have requested having the Root Query type to be exported to be able to use the technique of Mutation Payload Query, like so https://graphql-rules.com/rules/mutation-payload-query/, in which you return the whole Root Query type to allow the client to get the whatever data they want.
Describe the solution you'd like
For a mutation PollRatingSubmit, having a payload:
@ObjectType()
export class PollRatingSubmitPayload {
userErrors: UserErrorDto[];
query: QueryDto;
}
I want to achieve that QueryDto. There may be different strategies to consider, like running these two resolvers in sequence or in parallel https://discord.com/channels/520622812742811698/1088106037401366588/1088412449037885510.
Teachability, documentation, adoption, migration strategy
No response
What is the motivation / use case for changing the behavior?
As put in the linked 'rules' site, "... allow the client in one round-trip not only to call mutation but also to get a wagon of data to update their application." I'm using Relay GQL client which will allow me to simply spread their fragments in the Query payload and update the cache and UI whenever some of my mutations have effects on rather less relevant parts of the graph.
Is there an existing issue that is already proposing this?
Is your feature request related to a problem? Please describe it
Many people over many years have requested having the Root
Querytype to be exported to be able to use the technique of Mutation Payload Query, like so https://graphql-rules.com/rules/mutation-payload-query/, in which you return the whole RootQuerytype to allow the client to get the whatever data they want.Describe the solution you'd like
For a mutation
PollRatingSubmit, having a payload:I want to achieve that QueryDto. There may be different strategies to consider, like running these two resolvers in sequence or in parallel https://discord.com/channels/520622812742811698/1088106037401366588/1088412449037885510.
Teachability, documentation, adoption, migration strategy
No response
What is the motivation / use case for changing the behavior?
As put in the linked 'rules' site, "... allow the client in one round-trip not only to call mutation but also to get a wagon of data to update their application." I'm using Relay GQL client which will allow me to simply spread their fragments in the
Querypayload and update the cache and UI whenever some of my mutations have effects on rather less relevant parts of the graph.