I’ve got an app with a single, “top level” `Scaffo...

# compose

[Bradleycorn]

I’ve got an app with a single, “top level” Scaffold . It’s content slot contains a NavHost that displays a “screen” composable for the current destination. It’s similar to the Now In Android sample app from Google.

I’m curious how to best manage a FloatingActionButton (FAB) with this kind of architecture? the FAB’s display state is based on the current NavGraph destination that is being displayed by the NavHost. Some screens need to show a FAB, and others don’t. Managing the display state is pretty simple to do, setting the state based on the current destination.

Handling FAB click actions seems less straight forward. The action to take could vary significantly based on which destination/screen is displayed when the FAB is clicked. In some cases, it may be a simple navigation action. In others it may be more complicated (say, show a modal bottom sheet with content based on a selected item). I’m struggling with a good way to architect this. My brain keeps wanting to pass the FAB click action down to the currently displayed screen composable to let it handle it. But of course that breaks the primary rules of Unidirectional Data Flow.

How do you all handle cases like this?

[Stylianos Gakis]

My vote is for simply not having a global scaffold, and let each screen render itself as it wishes, it makes all of this dead simple.
What exactly do you need the global scaffold for in your case?

[brandonmcansh]

The only other option is a local provider that is () -> Unit

[Bradleycorn]

@Stylianos Gakis Yep I could totally do a “scaffold-per-screen” approach.

I’ve been toying around with the Now In Android app and their “single scaffold” approach and was just curious how they (or others) might handle a FAB with that setup. Their docs don’t really say why they did it that way. I might speculate that it’s either A.) They wanted to keep the same top app bar and bottom nav in place when navigating between top level destinations, or B.) something to do with the performance of Scaffold. Scaffold uses a SubComposeLayout, which as I understand it, is a bit expensive/inefficient. But those are just guesses.

[Stylianos Gakis]

What we do is that we have the bottom nav bar/nav rail as a common piece of the UI around the NavHost, since that one is agnostic to each screen’s functionality. There’s only some logic depending on which navigation destination we are in regarding if the nav bar will show or not.
No scaffolds included at all over here, just a simple row/column approach. And then each screen which has the full screen available to it (Minus the navrail or the bottom nav bar) can decide themselves if they need a Scaffold or if they can do their own normal column/row layout.

[Bradleycorn]

yeah I’ve done the “no-scaffolds” approach in the past as well