is it just me that is finding the recommended way to navigate and share a scaffold is absolutely ter...

# compose

[trevjones]

is it just me that is finding the recommended way to navigate and share a scaffold is absolutely terrible?
https://developer.android.com/jetpack/compose/navigation#bottom-nav

seems highly unlikely that we would avoid god object style coupling with that pattern

[Adam Powell]

which part? Any part of it can be abstracted using lambdas as event handlers and the pieces in between don't see any details of a NavController

[Ian Lake]

Yep, we had just talked about that separation between state in/events out code and Navigation code yesterday. Same thing applies with any call site where you want to trigger a navigate action: https://kotlinlang.slack.com/archives/CJLTWPH7S/p1645595702068129?thread_ts=1645552485.247699&cid=CJLTWPH7S

[trevjones]

It seems to me that being able to use compose navigation without having nested nav hosts and nav controllers you will end up having to build a handle every edge case type setup, but not just for bottom nav, also the toolbar, drawer, fab setups.

Or not sharing a scaffold and you pay the performance hit of a full recomp for every navigation event.

right now I am leaning toward building some way to nest navHosts and navControllers but hopefully in a form that allows me to retain deep linking without a headache.

[trevjones]

ok that convo thread matches where I was heading in terms of trying to keep the nav details isolated.

Just need to figure out the right way to avoid full recomps all over the place while getting some good separation in.

[Ian Lake]

You might also look at this related conversation about using an argument based approach to swap out that global UI rather than relying on specific routes: https://kotlinlang.slack.com/archives/CJLTWPH7S/p1628541488118700

[Ian Lake]

That kind of approach makes it more of a specific contract between your global UI and individual destinations on what should be displayed that still uses the NavController as the source of truth. Of course, that could be 'don't show a topbar at all on this particular screen, I'll take care of it myself'

[trevjones]

yeah that is the approach I was playing with last week. built a sort of "NavGraphLocal" by using view models scoped to the different backstack entry's that would search up the tree similar to the ViewTree*Owner pattern.

But getting the consumption pattern of it clean was where I stopped myself to make sure I wasn't going too far off the rails.

This is good help though, appreciate you digging these up