A modern programming language that makes developers happier.

kotlinlang

*About nested navigation graphs in `navigation-compose`*

I’ve noticed it’s possible to navigate to a nested destination without first navigating to its nested nav graph.
Please see code in thread.

```@Composable
fun MyApp() {
    val navController = rememberNavController()
    NavHost(
        navController = navController,
        startDestination = "screenA",
    ) {
        composable("screenA") { 
            ScreenA()
        }
        navigation(
            startDestination = "screenB",
            route = "nestedGraphRoute"
        ) {
            composable("screenB") {
                ScreenB()
            }
            composable("screenC") {
                ScreenC()
            }
        }
    }
}```
It is indeed possible to navigate from “screenA” directly to “screenB” or “screenC” without first navigating to “nestedGraphRoute”.
When navigating from “screenA” directly to “screenB” the `NavBackStackEntry` for “nestedGraphRoute” will be automagically pushed on the back stack.

• Is this working as intended?
• If yes, what is the usefulness of having a `route` param on the nested nav graph itself? Isn’t it an implementation detail that could be hidden?

Yes this is working as intended - routes follow the same behavior as any other internal deep link and can start any destination. You'd need a route on the nested graph itself if you want to navigate to the graph (i.e., if you are encapsulating the logic of your login flow, external users wouldn't need to know anything about the individual screens within that graph, just the graph itself) or if you want to store ViewModels, etc. at the navigation graph level. It is also the internal key used to uniquely define the destination, which is required for all destinations