https://kotlinlang.org logo
Join Slack
Powered by
Possibly dumb question: Is there a way to share fr...
# apollo-kotlin
f
Possibly dumb question: Is there a way to share fragments between services? I have only one module but want to maintain "module like" behavior between folders in this module. For example I have 
feature/home/GetHome.graphql
and 
shared/CategoryFragment.graphql
. These files are each in it's own 
service
so that I can specify a package name to the generated files. Now I want to access 
CategoryFragment
from 
GetHome
file but it errors out with `Cannot find fragment `Category``. Or maybe different question with the same outcome. Can I specify the package name of generated file more granularly so that the package names of different queries, mutations and fragments more resemble my defined project package structure?
m
Sounds like you're looking for 
packageNamesFromFilePaths()
Copy code
apollo {
  packageNamesFromFilePaths()
}
f
Oh 🤦‍♂️ I just wasted a few hours if it really is that simple. Thank you
m
It'll use the path to your fragment as a package name:
Copy code
feature/home/GetHome.graphql => feature.home.GetHome
shared/CategoryFragment.graphql => shared.CategoryFragment
You also can specify a root packageName that will be prepended everywhere
Copy code
apollo {
  packageNamesFromFilePaths("com.example")
}
You should certainly put everything in a single service if you go that route
There is usually a 1:1 mapping between an Apollo service and a GraphQL schema/endpoint
f
You just saved me, that was exactly what I needed. Thank you very much. Maybe this should be mentioned in 
Gradle plugin configuration
chapter in the documentation 🤔
Also, really good job with the library! 👏 I remember using 
3.0.0-beta
on some other project but it's completely different story now. And it got a rebrand from Android to Kotlin if I remember correctly.
m
Maybe this should be mentioned in 
Gradle plugin configuration
chapter in the documentation
https://github.com/apollographql/apollo-kotlin/pull/4135
❤️ 1
Also, really good job with the library! 👏 I remember using 
3.0.0-beta
on some other project but it's completely different story now.
Thanks 😊
f
Maybe this should be mentioned in 
Gradle plugin configuration
chapter in the documentation
I meant the official Apollo docs. Or is it planned and this is just a first step?
m
I don't want to give it too much importance as having a flat package name is way more simple, especially if/when you start using multi-modules
f
Fair enough 🤷‍♂️
m
The current Gradle documentation is relatively slim and only outlines a handful of options
We could/should document all the other ones
But in that case, I'd rather do everything all at once
(there are a lot of options down there...)
I was thinking maybe we should "just" copy paste a huge 
apollo {}
block with some comments, I've seen other projects do that, it reads quite well
f
Yeah, I was browsing the apollo gradle API while looking for something that could help me 😄
m
Yea, also the fact that groovy users (that are still the majority) do not get any hint doesn't help
f
That is a helpful way but I am afraid a lot of people could just copy that big block without knowing that a lot of stuff is optional. There should be a big disclaimer that it's only for purpose of showing all of the API. But otherwise that would save me a lot of time today 🙂
m
Just curious: was Ctrl-clicking the 
Service
class an option for you?
The Kdoc there is more detailed and it shows all the APIs. Ultimately, I wish this would become the source of truth as it can all be done inside IntelliJ
f
Yes, I did "Ctrl-click" to 
Service
and tried a few options. I don't know why I didn't find the 
packageNamesFromFilePaths
. There is a lot of stuff so I might've just scrolled past it 😕
(that's what I meant by "Yeah, I was browsing the apollo gradle API...")
m
Gotch
f
Maybe I just didn't know what I was looking for so the function name didn't sound like something useful for me
But I don't know how that could be changed so that I would find it 😅 Maybe categorizing the properties/functions somehow? 🤔 Making it more of a DSL rather than huge interface that does everything
m
Yep, we can look into that but it's certainly going to be breaking so for next major release
f
Sounds good 👍 And thanks for your quick help today
m
Sure thing!
97 Views
Open in Slack
PreviousNext
Powered by