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
Workaround for Name Too Long violations with responseBased code generation #5480
Workaround for Name Too Long violations with responseBased code generation #5480
Conversation
… gradle for making the system ingest a input.json file, which it can then take and create a tree definition of the system as a whole which will allow us to perform a fix for the Name Too Long exceptions in the Apollo system
… to extract into a flattened hierarchy
…ll flatten out the modules which we want when the name is too long. System will first check to see if the existing operation or fragment matches the naming convention and then split the IrModelGroups up, and then finally ensure that there are no name collisions.
…flatten models explicitly setup
…need to split up things
…de setup, we can omit them in the test cases
👷 Deploy request for apollo-android-docs pending review.Visit the deploys page to approve it
|
Hi 👋 thanks for looking into this!
Because of that exponential blowup, we strongly recommend using That being said, Back to your proposal, 2 early feedbacks:
|
Heads up there are now Apollo Compiler Plugins to customize the IR and flattening of models:
Would that work for your use case? |
@AdamMTGreenberg I'm going to close this one as the codebase has largely changed and there are now Apollo Compiler Plugins to help with this in hopefully a more flexible way. Let me know if you want to deep dive into this again, I'm happy to dive with you. |
Preface
For starters, I deeply apologies since this PR may violate:
It was a need we had for our current implementation within our consumption of the Apollo Kotlin code. I had to build a functional system for resolving this error in our current use, so regardless of the formal code review process, I had to come up with a working system.
Intro
This PR servers to help resolve the one of the known limitations of working with
responseBased
model generation.This solution allows us to take the output of the error output during code compilation where the class name is output in the form of
Class$With$A$Really$Long$Name$That$Breaks$Your$Build
and dictate how to flatten it via a secondary input in the form ofClass$With$A$Really$Long$Name
to flatten theName$That$Breaks$Your$Build
inner class.We dictate this via a gradle flag named
flattenExplicitly
which allows the user to dictate a JSON file which contains the set of classes which should be explicitly flattened in this manner. Multiple levels of the same class can be broken up at multiple levels in a successful manner. The JSON has the form of:(note: at the current time I did not implement the
renameTo
functionality since I wanted to make this PR as small as possible while I received review/we discussed)The bulk of the logic is in the
Flatten.kt
file where we build a tree of the potential explicitly flattened files, create dequeues of the linkedIrModel
s andIrModelGroup
s to flatten, and then finally rebuild the top-levelIrModelGroup
. The majority of the additional code is passing the vale offlattenExplicitly
throughout the system and supporting test classes and fake GraphQL genreated output and data. Additionally there are a few data models to try and simplify the hierarchy of the explicitly flattened generated classes.Notes
flatten
, does not support java code genresponseBased
limitations, does not supportoperationBased
models (in tests it works - but there are issues with adapters which have yet to be resolved)