Looking at `compose-navigation`, it seems like the...

# compose

[Fudge]

Looking at compose-navigation, it seems like the api is quite akward to use. It requires predefining routes with Strings, and then specifying those Strings again when you want to navigate to those routes. And then passing parameters into the routes is a whole world of complication. What will you do when you need to pass real objects? Serialization?

Why not a solution that looks like this, in the way Flutter did it?

onClick = { navigate { TheOtherComposable(obj1, obj2) } }

[Ian Lake]

We've talked about this a couple of times before if you search for Navigation arguments, but you should treat routes like web URLs. In a restful API, you pass the ID of an item, not the item itself

[Fudge]

I don't see discussion about the motivation or why this was the way navigation was handled, instead of passing real composables to navigate {}.

[Ian Lake]

That's how the Navigation Component works. You define the graph ahead of time and that's what controls the creation of the Composables and ensures that you can restore your back stack and all of the Composables after not just a config change (which would already wipe out any Composable instances you create) but also after process death and recreation, where all you have is saved instance state

[Kshitij Patil]

Maybe we could write an adapter class to generate those url strings 😛

I've already worked around to generate route from label name of BottomNavigation

val route: String
    get() = this.label
        .replace(" ", "")
        .toLowerCase(Locale.ROOT)

of course my labels are always gonna be in English so I did this. If you've localized strings, please don't do this as routes are always going to be English

[Ian Lake]

Yeah, that seems like a terribly fragile solution that I would strongly recommend against.