[RFE] Support dumping data structures to a separate module

[mathstuf]

It'd be nice to have a way to dump all types from a schema into a module and then using that module to pull all of the data types for queries. This would simplify creating impl From<query_name::SomeGQLType> for each query's copy of relevant types.

Maybe:

#[derive(GraphQLQuery)]
#[graphql(schema_path = "…", only_types)]
pub struct SchemaTypes;

#[derive(GraphQLQuery)]
#[graphql(schema_path = "…", query_path = "…", types_from = schema_types)]
pub struct SchemaTypes;

Not sure how feasible this is.

[tomhoule]

Good point about the From impls. Let's think about it. This would be possible for GraphQL enums, scalars and fragments, since those always have the same fields, but I don't think it would work for objects, unions and interfaces because you can select different fields on them in different places in the same query or in different queries.

One small problem I see is that you could have one document (a .graphql file) with a fragment called FullResponse or something equally generic, and then, in another file, another FullResponse fragment - the names would clash.

Since scalars are just type aliases, that would just leave enums to be shared through the whole app, while fragments could be reused by multiple queries in the same document.

[mathstuf]

The other issue with fragments is when they aren't used as a complete type:

query {
  ...SomeFragment
  anotherField
}

Due to serde(flatten), a From<SomeFragment> wouldn't work here. I'm OK with just handling the types in the full schema though (I'm mainly looking at just enum and scalar). Looking at the spec, fragments aren't even allowed in the schema, so unless schema_path supports only_types as well, we shouldn't need to bother with it.

[mathstuf]

Having now used fragments, I see that the way the code is generated, dumping fragments to the module space also is wanted. The serde(flatten) bit isn't important for this; each fragment gets its own type.

[tomhoule]

Good point, I think this is a feature we want if we manage to find a solution to the fragment names clashing problem (nested modules?).

[mathstuf]

Well, fragments are always going to be in the query side, so how could they clash when sharing a schema namespace?

[tomhoule]

There has been progress on this. I think we can go a lot further with the CLI codegen and build script workflow that we are going to build. Maybe we can reuse that infrastructure in the derive flow when it is implemented. See issue #134 for some discussion.