I’ve been starting to play with the compose versio...
# compose
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)
No, you just
. 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
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:
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.
Using a mock NavController hasn't been a recommendation for a few years now - not since we added
for a fully operational fake
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
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:
Copy code
onNavigate = { navController.navigate(it) },
but this is guetting passed to the drawer function so it doesn’t care about the nav controller.
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.
Just like how you can have different lambda implementations for the same composable screen