Will DestinationNavHost know how to pass navContro...

# compose-destinations

[dave08]

Will DestinationNavHost know how to pass navController::navigate, navController::navigateUp to my screens? It doesn't seem like I can register them as dependencies...

[dave08]

I'd rather not pass the navController itself.

[Rafael Costa]

I would use DestinationsNavigator in your screens.
Since it's an interface, it's inherently decoupled from NavController, so you can safely depend on it.

[dave08]

I'm currently refactoring, and I have a bunch of screens with those refs, is there any way to pass those lambdas before I refactor to use the DestinationsNavigator?

[Rafael Costa]

If you don't like that, you have two options:
1. Manually call your composables, similar to how you'd do it with official lib, but you don't have to manually call all of them, just the ones you need to.
See here: https://composedestinations.rafaelcosta.xyz/destination-arguments/navhost-level-parameters#manually-call-your-screen-composable
2. Create smaller fun interfaces like

fun interface NavigateUp {
    fun invoke()
}

And pass it via dependency(NavigateUp { navController.navigateUp })

[Rafael Costa]

> I'm currently refactoring, and I have a bunch of screens with those refs, is there any way to pass those lambdas before I refactor to use the DestinationsNavigator?
I see. Personally I would bite the bullet and change all those lambdas with DestinationsNavigator. Of course, that is if that's the end goal anyway

[dave08]

Originally I did it like that according to the Android docs that seem to discourage passing down nav controllers or the likes. I guess at the Screen level I could just pass down anything I need from the DestinationsNavigator instead. So I understand that lambda deps aren't supported unless they're typed like fun interfaces... I guess I could understand that (otherwise compose-destinations would need to become a full fledged DI like Dagger2 w/ named dependencies, etc... 🙃)

[Rafael Costa]

Yeah. That recommendation is there mostly to make your screen composables more previewable and testable in isolation from navigation. Since DestinationsNavigator is an interface, you can pass a noop implementation (one is already available through EmptyDestinationsNavigator) or any mock for tests.
Besides this, there are philosophical arguments that I see little value in.
In any case, you should look at the annotated Composable the same way you look at the lambda in composable {} with official navigation. Meaning, even if you depend on NavController there, it’s not a big deal as long as you also have a more “pure” composable that receives only state and lambdas. You can use this space also to get the ViewModel and collect state from it.
This dual composable setup is very common even without Compose Destinations.