-
Notifications
You must be signed in to change notification settings - Fork 124
reuse fragments by their selection set #437
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
base: master
Are you sure you want to change the base?
Conversation
…definitions for field selections that include only a single inline fragment spread" This reverts commit 276032e.
Hey again @knaeckeKami :D And btw I had to manually modify fery_generator bcs the current version 0.8.2. expects dataClassConfig |
Hi @LiLatee and @knaeckeKami I am currently have fatal issue in my codebase:
My schema is notably quite large and union-heavy. And I believe I have now added the union that the JIT compiler can handle. Line counts that work:
Line counts that result in failure:
I'm struggling right now to find a good solution. Do you have any ideas on what I can do in the scenario? Thanks |
Hi @dav3rin dependency_overrides:
## We use our custom version of `gql_build` and `gql_code_builder` with somehow fixed `tristate_optionals` feature.
gql_build:
git:
ref: 7edbf44ec1c929a1ed1a9e8e79ca8949ba1ed843
url: https://github.com/LiLatee/flutter_gql.git
path: codegen/gql_build
gql_code_builder:
git:
ref: 7edbf44ec1c929a1ed1a9e8e79ca8949ba1ed843
url: https://github.com/LiLatee/flutter_gql.git
path: codegen/gql_code_builder
gql_tristate_value:
git:
ref: 7edbf44ec1c929a1ed1a9e8e79ca8949ba1ed843
url: https://github.com/LiLatee/flutter_gql.git
path: codegen/gql_tristate_value
dev_dependencies:
## We use our custom version of ferry_generator with fixed `tristate_optional` feature.
ferry_generator:
git:
ref: b3c08b68cccc0f18c59b7fc816bdacb45a7303de
url: https://github.com/lilatee/ferry.git
path: packages/ferry_generator |
Hey @LiLatee Thanks for the quick reply. I gave your fork a test. As you predicted, some serializers are missing. The missing serializers are actually fine in my case. I just had to change my references to the fragment instead of the query subclass. I do have a problem however with missing data classes.
The simplified gql schema looks like this:
|
This is just an idea for an alternative implementation to #417
This is a different approach to reusing fragments and reduce duplication in the code.
The idea is: Keep a Map of
(TypeName ,BuiltSet<SelectionNode>) -> Reference
for already generated fragments.This will use the actual selections for figuring out whether a new class needs to be created or a fragment can be reused.
TODO: try if reusing generated subclasses for inline fragment spreads can also be optimized, without potential conflicts in types
TODO: potentially this can be extended to not only reuse fragments but all generated classes, if they have the same selections.
Drawbacks: the names of the generated classes are less stable and could change by adding new fragments which can be used
Advantage: IMO simpler to understand, easier to extend