Or it does not have to be a graph? It can also be ...

# compose-destinations

[Steven Yang]

Or it does not have to be a graph? It can also be implemented as two routes in two graphs wrapping the same composable component.

What's the best practice when some screens need to be shown in multiple graphs?

[Rafael Costa]

On V2, you can have something like this:

@Destination<ProfileSettingsGraph>
@Destination<RootGraph>
@Composable
fun SomeScreen() {}

[Rafael Costa]

for example

[Rafael Costa]

It would generate two Destinations, like ProfileSettingsSomeScreenDestination and RootSomeScreenDestination

[Rafael Costa]

each belonging to the corresponding graph

[Rafael Costa]

On V1, you'd need two Composables each annotated with @Destination and with the respective @NavGraph and then both would call the same composable internally.

[Suhaib Kazi]

This is something i was looking for

I have a doubt regarding the navargs
how does it resolve if different navargs classes are used?

[Suhaib Kazi]

Since multiple @Destination calls are allowed on a Composable

is there any way to essentially attach a NavGraph inside multiple NavHost?

@NavGraph<UserGraph>(visibility = CodeGenVisibility.INTERNAL)
@NavGraph<Unauthenicated>(visibility = CodeGenVisibility.INTERNAL)
annotation class SettingsGraph

Something like this maybe?