-
Notifications
You must be signed in to change notification settings - Fork 651
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
Incorrect Type Conversion for Lists with Shared-model type #898
Comments
If you want them to share the same model you have to use fragment:
It will generate At the same time I agree that we should recognize identical sub-queries and have generated only one model class instead of 2 identical ones. |
@sav007 That's exactly what I ended up doing but, again, because it is still 2 different models my RecyclerView code looks kinda ugly. I will proceed with the suggestion for the time being. However, is there any chance that a future version of Apollo-Android could enhance/fix this so that a single model class is used? Thanks for the feedback. |
We encourage you to use ViewModels for UI, that layer of abstraction will give you flexibility and resolve such issues, as in many cases generated models don't satisfies UI needs and requires to have additional fields or different types to present on UI |
That's true but there really shouldn't be a reason for the generated code to break the contract defined in the schema.json file (i.e. the 2 lists use the same data type). Thanks for the feedback. I'll revisit my solution. |
Closing for now. Let us know if any recommendations of how to make experience better. |
We have a subquery photos where 2 fields (or subqueries) called published and archived that share the same properties or subqueries:
The schema.json generated by Apollo Codegen is shown below. As you can see, both published and archived are objects of type LIST with items of type VenuePhoto:
The current issue we are facing with Apollo Android is that the generated models are of the following type;
where we are expecting the following:
A failed attempt to coerce the tool to generate the right models was to extra everything inside
photos{}
as a fragment but that did not change the results.I would appreciate some feedback as to whether the current behavior and model output is either a bug or if it is working as intended and there is a missing feature or flag that I need to incorporate in my
*.graphql
file to achieve the desired results.The text was updated successfully, but these errors were encountered: