https://kotlinlang.org logo
Join Slack
Powered by
Hi all! I've just release my first v2 alpha versio...
# compose-destinations
r
Hi all! I've just release my first v2 alpha version 🙌 This was a lot of work for me, but I really believe it will be worth it. For now, only documentation there is is this migration guide: https://composedestinations.rafaelcosta.xyz/migrating-to-v2 I'd love it if you could try it and let me know how it went! I look forward to any kind of feedback 🙏
👀 1
d
I'm a bit sceptic of if a type parameter on EVERY destination annotation is more readable than the "old" separate annotation...
I haven't yet seen any libraries using type parameter on annotations in the first place? But maybe at least not requiring them for destinations in the root graph?
r
I'm a bit sceptic of if a type parameter on EVERY destination annotation is more readable than the "old" separate annotation...
Any specific reason for it not to be as readable? It's just moving some characters around 🙂 It allows us to have multiple Destination annotations in a given Composable function, each having its own NavGraph. Otherwise with multiple Destination multiple NavGraphs it would be impossible to know which is which. There's also other side benefits on the ergonomics of defining a start for a graph, etc.
d
Also, I'm confused about all the files not being generated... and their "replacements", what does that mean for the end-user... I think most people don't go too far in looking at what's generated as long as things work smoothly... (which is one of the reasons I like this library... I didn't have to dig too far to use it 😁)
Defining a start of a graph was deprecated in the older version...
On a destination annotation, I mean...
r
I haven't yet seen any libraries using type parameter on annotations in the first place?
Why should that be a reason to not do it? 🤔
But maybe at least not requiring them for destinations in the root graph?
You can always do something like
Copy code
typealias RootDestination = Destination<RootGraph>
(Although I should test that it works 😄 with KSP)
> Defining a start of a graph was deprecated in the older version... > On a destination annotation, I mean... Yes, but know it's back as the way to do it, since the graph is part of the Destination itself 🙂 > Also, I'm confused about all the files not being generated... and their "replacements", what does that mean for the end-user... I think most people don't go too far in looking at what's generated as long as things work smoothly... (which is one of the reasons I like this library... I didn't have to dig too far to use it 😁) If you're not using any of it, no need to worry 🙂
d
Yeah, maybe I'd use a 
typealias
in that case... if you have a reason (not just aesthetics...) for it that's fine, just think that a lot of people will only need one graph, and that should be easy and short.
Maybe have that typealias built in as a short cut?
✅ 1
r
That is a valid point yes, I'm making it slightly more characters for those. But I think it's good even for them to have a mental model of "RootGraph" means I get a 
NavGraphs.root
to pass to DestinationsNavHost
hopefully it's not too inconvenient to add the <RootGraph> 🙂
Maybe have that typealias built in as a short cut?
That's a possibility, yes 🙂 Let's see if I get more feedback like yours!
that is why we have this alpha phase!
Would 
@RootDestination
really be so much better than 
@Destination<RootGraph>
though? 😛 Especially considering, it is easier to understand how to use custom nav graphs there instead of Root 🤔 I feel like this is going to be just fine 🤞 😅
d
Yeah, well maybe, I guess I'm just a bit biased... I never saw frameworks like Dagger 2 doing 
@Component<Singleton>
to make it clear that only 
Singleton
scope can be used there... maybe you'll be the first to give them the idea 😉. We're all just too used to scoping with a separate annotation, I actually never even thought it was possible 😊.
r
I found out recently too, from this article: https://blog.p-y.wtf/diy-your-own-dependency-injection-library And it was exactly what I was looking for for a while. I needed a straight clear pair Destination -> NavGraph. Multiple annotations don't work in this case.
I also do think it looks better and more explicit (even if slightly more verbose in the root graph case).
it's possible the reason we haven't seen it yet, is that it wasn't possible with Java annotations / KAPT / APT. And a lot of frameworks we use, have had to consider what users were used to pre kotlin / pre KSP.
Although, I'm just guessing here 🙂
Was randomly skimming through the article and found this paragraph:
Unfortunately, Dagger 2 is a java annotation processor and, unlike Kotlin, Java annotations cannot have type parameters:
So yes, I was right, type arguments aren't a thing on java, so that explains why we haven't seen this before.
👍🏼 1
Open in Slack
PreviousNext
Powered by