What are the thoughts on using something like `Loc...

# compose-android

[dazza5000]

What are the thoughts on using something like LocalView.current.findNavController() vs passing the navController down as an argument?

[andrew]

You can always expose your navcontroller as a composition local

[andrew]

But imo, I’d always expose it as an argument, even if it has a default impl that either consumes the composition local, or receives it directly

[andrew]

Grants more flexibility in testing and usage, depending on the component

[Ian Lake]

Don't do either, ever, as explained in the testing guide: https://developer.android.com/develop/ui/compose/navigation#testing

[Ian Lake]

Keep all of your screens completely independent of whatever navigation code you are using

[andrew]

I have overloads with generic functionality that are independent from the nav library

[andrew]

I always make sure I have an onBack or onSelect parameter or whatever, and then I also keep a convenience method for the navigation to fill in reasonable defaults

[andrew]

I should have been more specific!

[andrew]

I always make sure state can be hoisted

[andrew]

And events

[Ian Lake]

We have a specific page on the approach you need once you get beyond just a single module (where multiple modules define their own nested graphs and you need to cross link them) - you'll note that the NavController never goes beyond the NavGraphBuilder extensions you build: https://developer.android.com/guide/navigation/design/encapsulate