I’ve been starting to play with the compose version of NavController. I’ve got a basic drawer menu ...

# compose

[mattinger]

I’ve been starting to play with the compose version of NavController. I’ve got a basic drawer menu working, but it makes me wonder if there’s an equivalent of the “<action>” tag when building a NavController via composables. The nice thing about the “<action>” tag is that it makes a clearly defined graph and lays out where you can go from any given destination. I’m not seeing that in the documentation for navigation with compose (https://developer.android.com/jetpack/compose/navigation)

[Ian Lake]

No, you just navigate(). If you want to make your own extension method that pre-defines NavOptions, etc. if you want to reuse it in multiple places, go for it - it is just Kotlin code

[mattinger]

Thanks @Ian Lake. It just seems like it’s a little less safe than using an xml based graph (though much more convenient). I’m in the habit of always navigating with actions so that I can control the popUpTo, etc…. without actually caring about where things go. We’d generally name things like this: action_screenName_next so that the fragment itself didn’t have to care if there were pops needed to get to the next screen, or which screen was next. It made testing very easy, because you could put in a mock navController and just verify on the navigate function.

[Ian Lake]

Using a mock NavController hasn't been a recommendation for a few years now - not since we added TestNavHostController for a fully operational fake

[Ian Lake]

As per the testing guide (https://developer.android.com/jetpack/compose/navigation#testing), it is way easier in Compose land to co-locate your navigate calls away from your code by passing lambdas down - it also means your entire screen can be tested separately from a NavController at all

[mattinger]

That’s what i’m doing right now already. Granted it’s limited to a drawer menu because i haven’t done a multi screen / single activity flow with it yet:

[mattinger]

onNavigate = { navController.navigate(it) },

[mattinger]

but this is guetting passed to the drawer function so it doesn’t care about the nav controller.

[mattinger]

It just seems more comfortable using actions, i guess due to familiarity. It always seemed wrong to me to code destinations directly into the code itself. Actions seem more flexible, especially when you re-use a fragment in different flows, it can have the same action ids., but different destinations.

[Ian Lake]

Just like how you can have different lambda implementations for the same composable screen