https://kotlinlang.org logo
Join Slack
Powered by
:wave: is there any way of navigating to a NavGra...
# compose-destinations
m
👋 is there any way of navigating to a NavGraph (or its start destination) with an argument?
r
This was the main limitation of v1. NavGraphs don’t have nav args and their start destination also couldn’t, even if they’re nested graphs.
But it is possible now with v2
😱 1
Not sure what is your case.. are you just now trying the library? Are you in production already?
m
We're in production since quite a while back 🙂
r
V2 is in alpha and it still lacks most documentation.. the only docs I did so far are about migration from v1
m
Yeah, I saw it today! Does it mention this?
r
If you can’t use v2 yet, typical workaround was to set a non mandatory nav arg to that start destination
And then assert that it is there on the other side, making sure you always pass it (even though it’s not required at compile time)
It actually doesn’t because it’s a new feature, so not really something needed for someone migrating
m
Ah, I see
r
But it should be pretty straightforward. Just put nav args on the start destination, and it will work. When navigating to that nav graph (it’s also possible now) it will also require the arguments of its start destination
But ofc if you go this route, you’d have to go through the migration steps 😜 (which you need to do eventually..)
And also accept that some APIs may change during this alpha phase of v2
m
Yeah, I mean, it depends on how experimental you would deem the alphas to be? We're not completely shy to go for alphas in general
r
Im confident it works well, it’s more about the APIs stability. Meaning, some could change again in near future
m
API changes shouldn't be a problem
r
Ok, then I’d say go for it. It would also be really helpful for me to get some real feedback 🙂
m
we're quite invested but I understand that you can't exactly tell me how big/what changes you are planning to make 😄
r
Right now, no plans to change anything. But it will depend on the feedback I get during the alpha. I don’t expect a lot of changes though. Definitely not hard changes that would require lots of work from you
Do you have a multi module app? Because that’s where lot of changes were done for v2. For the better though
m
That sounds good! This specific issue of passing arguments to navGraph is a pretty big thing for us, since we have a structure of a sort of home screen that leads to detail screens that need an id as an argument, while a lot of them also are NavGraphs
the navigation parts are all in the main module, so I think that qualifies as a single module set-up
r
Alright, so it should be fairly easy to adopt v2.. don’t panic with all the steps in the guide 😅 Most won’t be for you probably.. but do read the headers for each of them. And let me know how it goes, even if it’s positive feedback. I want all feedback ahah
m
yeah, I looked through it earlier and it seemed pretty straight forward, mostly the changes to all 
@Destination
and 
@NavGraph
annotations 😅
r
Yes, sorry for that 😜
m
🤷 I'm sure you had good reasons 😄
r
New major version, gotta make the most of it. I don’t want to break APIs on minor bumps ahah
m
Does this use any other alpha versions or is it only for the major bump on Compose Destinations?
r
So.. there’s two versions 2.0.0-alpha02 and 2.1.0-alpha02
The first is only about compose destinations and it uses all stable versions from compose 1.6
The second uses the current alpha compose 1.7 dependencies
m
freedom of choice! Awesome!
👍 1
@Rafael Costa This bullet point might be nice to have higher up, since it changes the dependencies. Perhaps even have it not collapsed
That would be the first thing I'm doing before moving on to any other migration
r
Hi Magnus. That's fair 👍 I guess I was looking at "bottom sheet" destinations as optional and if not using them, then things stayed the same. But it's even likely that some are still using animations core to have animations (even if it was not needed anymore on latest versions).
So, let me improve this 👍
👍 1
What do you think?
still collapsible since some might not care I guess. But moved it to the first collapsible point and changed the header to make it more explicit
m
Another one: Did you try the new 
@ActivityDestination<NavGraph>
format on a java activity? 😬
That one looks great!
r
Whaaat? 😅
yeah, that might not work 😛
Seems I already put Java out of my head for good
m
I wish I had, too 😂
r
Guess, for Activity (since for composables, we need Kotlin anyway) I can accept a class as a parameter instead of the annotation type argument
so like
Copy code
@ActivityDestination(navGraph = MyAnnotationGraph::class)
👍 1
I'm tempted to have 
JavaActivityDestination
😛
to keep consistency as long as we are working on kotlin
m
I would be fine with that tbh, it's not exactly the main purpose of this library 😄
👍 1
r
Already implemented, will release after lunch 😛
🔥 1
m
I'm just gonna keep using this thread for another migration thing... I have a destination where the generated Destination class has a 
FooScreenDestinationNavArgs
, where 
FooScreen
is my Composable. This NavArgs data class has a single parameter, but this means the entire Destination becomes of type 
TypedDestinationSpec<FooScreenDestinationNavArgs>
, which causes a compilation error in the generated 
FooGraph
(it expects a 
TypedRoute<Unit>
).
r
Is 
FooScreen
the start destination of 
FooGraph
?
m
yes
the parameter is nullable (
String? = null
)
r
interesting, can you paste the generated Destination and NavGraph?
or on DM
m
sure
3 Views
Open in Slack
PreviousNext
Powered by