Summary
This is connected to #901 in that we'd like to expand what is done with GraphQL Code Generator.
The basic idea is to have code generation that can keep up with Relay so that we enable and encourage better fragment best practices and enable a better control of the operation/fragment pipeline in the future. For now the goal is to be able to write queries with gql tags, interpolate fragments into them from other files (also written with gql tags), and to expose all gql tags A) with types somehow, and B) have separate __generated files with a large combined operation.
This encourages to define data requirements in the form of fragments in several places, and it actually creates a very compelling end to end experience with urql, where it becomes more Relay/Framework-like and encourages that paradigm. (Together with #964 this will be really strong)
Proposed Solution
TBD (This is still a placeholder and no proposed implementation path exists yet)
Requirements
TBD
cc @JoviDeCroock @dotansimha
Summary
This is connected to #901 in that we'd like to expand what is done with GraphQL Code Generator.
The basic idea is to have code generation that can keep up with Relay so that we enable and encourage better fragment best practices and enable a better control of the operation/fragment pipeline in the future. For now the goal is to be able to write queries with
gqltags, interpolate fragments into them from other files (also written withgqltags), and to expose allgqltags A) with types somehow, and B) have separate__generatedfiles with a large combined operation.This encourages to define data requirements in the form of fragments in several places, and it actually creates a very compelling end to end experience with urql, where it becomes more Relay/Framework-like and encourages that paradigm. (Together with #964 this will be really strong)
Proposed Solution
TBD (This is still a placeholder and no proposed implementation path exists yet)
Requirements
TBD
cc @JoviDeCroock @dotansimha