I have my navigation components setup similar to the suggestions in the bottom Navigation example in the Navigation Compose docs. I have a sealed class,

Destination

to define my destinations, and each has a

route

parameter. Then, on each destination, I add a

buildRoute(...): String

method that can be called to build a route string with the proper formatting. So, a basic version of my sealed class looks like:

sealed class Destination(val route: String, val title: String) {
    object Product(route="/path/to/Products/{category}/{id}", title="Product") {
        fun buildRoute(category: String, id: Int) {
            return route.replace("{category}", category).replace("{id}, id)
        }
    }
}

And when I want to navigate, I’d do something like:

val productDestination = Destination.Product.buildRoute(myProduct.category, myProduct.id)
navController.navigate(productDestination)

How do you avoid littering your apps with destination route strings?

If you don't want to go that far, then you'll want to generally structure things into three layers: 1. An ideally fully KMP, type safe Screen that is fully independent of any Navigation framework (this is what our testing guide specifically recommends) - state in, events out 2. Your navigation graph in a file as a

fun NavGraphBuilder.yourGraph(onNavigateToFriendsList: (userId: String) -> Unit))

method that encapsulates the creation of the graph (what our nested graph guide specifically calls out for segmenting your graph across separate modules). Note that

NavGraphBuilder

extension should take a lambda for each external navigation call (i.e., a call to navigate defined in some other graph/module - we'll use this in part 3). That same file should define the subset of

fun NavController.navigateToProfile(userId: String)

extension methods that make up the public interface of that module 3. Your app module (or the one with the

NavHost

) then calls each

yourGraph()

method, calling the correct

navController.navigateToFriendsList(userId)

from module A when

onNavigateToFriendsList

defined in module B is called. Obviously if you have graphs nested within graphs, add layers of 1 and 2 as you build up your graph Thus you've now built out an entirely type safe API that fully defines the exact API surface you need that fully supports as many independent modules as you want. All without any idea of routes leaking out of that file in step 2 (which, if you've split up your modules correctly, is probably just a single file for that module) or your navigation code being endemic to each one of your screens (as they'd be defined independent of Navigation in step 1).

FWIW, a Scaffold is quite expensive (since it uses

SubcomposeLayout

) - you probably just want a

Column

for anything inside an individual screen 🙂

Also hmm, in order to also be able to not navigate away when there’s already a navigation going on, as suggested here, then the lambdas need to be in this shape

fun NavGraphBuilder.yourGraph(getBackStackEntry: (route: String) -> NavBackStackEntry, onNavigateToFriendsList: (backStackEntry: NavBackStackEntry, userId: String) -> Unit)).

Note the addition of

backStackEntry: NavBackStackEntry

in the navigate event, so that we can also check on the lifecycle state before the navigation happens. So call site changes to

yourGraph(
  getBackStackEntry = navController::getBackStackEntry,
  onNavigateToFriendsList = { backStackEntry, userId ->
    if (backStackEntry.lifecycle.currentState == Lifecycle.State.RESUMED) {
      navController.navigate... 
    }
  }
)

edit: Right, Jetsnack already does showcase this ✅