Sharing input/output types when they match

[cerupcat]

Per our slack conversation https://apollographql.slack.com/archives/C24NKC5DY/p1504670856000092 this issue is to discuss better solutions for sharing input/output types when they match.

For example, we have a type Answer. In a response, we have an array of [Answer]. In the input type, we also have an array of [Answer]. In both cases, Anser has the same fields. However, since one is an input type and the other is an output type, it's not possible to easily convert one to another without manually mapping the fields from one to another.

Are there any other recommendations for handling cases like this? For us, this usually occurs when the output type is something we need to modify (like a form) and then send back to the server to save any changes.

[designatednerd]

This is a good one - I know I've been wanting to do some stuff with CodeGen to get fragments annotated as protocols so you can pass those fragments regardless of the query - I'll have to do some digging to see what we can do in terms of potentially making the response types also conform to that.

[alexander-larsson]

Has there been any progress on this? I find it very cumbersome that types that are the same (in terms of what data they contain) are different depending on what query they are a part of. I have fiddled with different solutions but none has really worked out in a good way.

What I have tried:
Just mapping the types: Too much boilerplate.
Introducing a third type and mapping to that: Even more biolerplate.
Introducing a Protocol and then conforming the types to that. Works well for types that only contains properties with standard types like String, Int, Date and so on but not when it contains a GraphQL generated type. The type does not automatically conform with no changes in that case. (I create an extension with no body to make it conform to the common protocol)

The real solution is for the CodeGen to handle this but I realize that it is a hard problem to solve.

[designatednerd]

This is something we're still looking into for new codegen, but after a year and a half of digging these are the potential issues I see:

• In many cases, input objects are defined differently in the schema than response objects, even if they're ultimately the same object.
• Input objects have to handle the difference between sending nothing (which doesn't touch any existing value on the server), sending a null value (which deletes any existing value on the server), and an updated value (which actually updates the value). In the current codegen this is represented as a double-optional, and in new codegen we're representing this as a GraphQLOptional. In either case, this makes it somewhat harder to define a protocol that works across both received objects and input objects because of the type differences.

You're definitely correct that this is a hard problem to solve - honestly all the codegen stuff has been way, way harder than I expected which is why it's comically behind. But those are at least some things we'll be thinking about as we move it forward.

[alexander-larsson]

I’m also having problems with very similar queries that return the same thing but they get different types. This happens for example when I apply different filters to essentialy the same query. Maybe I’m missing something here though?

[designatednerd]

I’m also having problems with very similar queries that return the same thing but they get different types.

Are you talking about the different nested types that are generated per-query, or different __typename types from the server?

If it's the former, you probably want to look into using fragments for the overlapping fields. If it's the latter, that's something altogether different.

[alexander-larsson]

It was the former. Thank you! My code is so much more beautiful now! 😃

[calvincestari]

Hi 👋🏻 - after looking at this issue again in preparation for the upcoming 1.0 release we've decided not to take this request into 1.0. If this is important to you please let us know in this issue - thank you.