menu

Apollo

A community of developers, designers and others who love Apollo and GraphQL. 🚀

Channels
# All channels
view-forward
# General
view-forward
# Apollo Angular
view-forward
# Announcements
view-forward
# Apollo Android
view-forward
# Apollo Client
view-forward
# Apollo iOS
view-forward
# Apollo Link
view-forward
# Apollo Link Rest
view-forward
# Local State
view-forward
# Apollo Studio
view-forward
# Apollo Server
view-forward
# Apollo Tooling
view-forward
# Contributing
view-forward
# Docs
view-forward
# Events
view-forward
# GraphQL Tools
view-forward
# Jobs
view-forward
# Random
view-forward
# React Apollo
view-forward
# Showcase
view-forward
# Subscriptions
view-forward
# Testing
view-forward
# Vue Apollo
view-forward
Team

Object Oriented Responses

June 10, 2020 at 4:09pm
The Apollo community has a new home. This thread is preserved for historical purposes. The content of this conversation may be innaccurrate or out of date. Go to new community home →

Object Oriented Responses

June 10, 2020 at 4:09pm
Thank you for creating this library. I am experimenting with using it but I'm up against a stumbling block. I have a number of queries that return essentially the same data shape. However, when I generate the java code to represent these queries (using the maven java apollo generator), there is no way (that I can figure out) to be able to access the Response Data objects in a general way so when I access common fields I can reuse code.
For example:
QueryA.Data.CommonConnection.Edges.Node.value QueryB.Data.CommonConnection.Edges.Node.value
each of these are different classes and so when I get the value at the end, I need to write the same code twice. It would be lovely if I could use generics with some common parent class in the generated code. Am I missing something fundamental?

June 10, 2020 at 8:46pm
Hi ! To do that you can typically use GraphQL Fragments. There is some documentation in the Android doc. It's about mutations but the same works for queries as well.
  • reply
  • like

June 11, 2020 at 1:27pm
Thank you. I'm familiar with Fragments. But I'm not sure how that solves this issue. I have fragments in my one query that are exactly the same as fragments in my other query and yet the generator makes two separate classes to represent them.
  • reply
  • like
Are they exactly the same in content or do they actually have the same name? If they have the same name, they should be generated only once:
fragment launchFragment on Launch {
id
site
}
query LaunchDetails($id:ID!) {
launch(id: $id) {
...launchFragment
}
}
query LaunchList {
launches {
launches {
...launchFragment
}
}
}
This should generate only one Fragment data class. If that's not the case, it's most likely a bug. Can you share your queries?
Edited
  • reply
  • like
the fragment portion is the exact same.. for example
  • reply
  • like
... on SomeClass {
connectionA {
edges {
node {
fielda
fieldb
}
}
}
}
  • reply
  • like
that fragment is in 2 queries.. it's exactly the same.. the queries only differ in one way (the second query adds some connections to the first)
  • reply
  • like
what I would expect is to see the same class "SomeClass.java" used in both query classes (kind of like the way it seems that type enums are generated and reused)
  • reply
  • like
oh I'm sorry. I hadn't seen your code sample
  • reply
  • like
I was using fragments differently. I didn't know you could simply make a fragment to encapsulate actual "fragments" of graphql query language (note I was using the "on" operator). So, do all of the fragments and usage of said fragments need to be in the same query file?
  • reply
  • like
Sorry, I typed 'enter' too fast, I'll never get used to the tiny spectrum input field 🙃. Inline fragments like you use will generate different classes but if you extract them in "regular" fragments, they will be shared. It shouldn't be required for them to be in the same file as the queries, I think as long as they're referenced with the same name everywhere, they'll be shared.
  • reply
  • like
This is amazing.. I tested it and it works.. thank you. Before this I was playing around with reflection to get the common fields across the classes but that was getting complicated quite quickly.
  • reply
  • like
while I have you .. can you tell me what these two config options are all about? I can't find documentation
  • reply
  • like
<generateAsInternal>false</generateAsInternal>
<generateVisitorForPolymorphicDatatypes>false</generateVisitorForPolymorphicDatatypes>
  • reply
  • like
The documentation for the Gradle options are at https://www.apollographql.com/docs/android/essentials/plugin-configuration/. The source code is also a good source of information. generateAsInternal is useful if you don't want your generated models to leak outside your module. generateVisitorForPolymorphicDatatypes is a helper in case you have a lot of polymorphic types. See this issue for more details.
  • reply
  • like
thanks again!
  • reply
  • like