Architecture and FloatingActionButton implementation

[Bradleycorn]

The app architecture uses a single "top level" Scaffold for the entire app in the NiaApp Composable. I like that because scaffold uses SubComposeLayout, and from what I understand it is relatively expensive/inefficient.

I'm curious if the architecture might need to change though if there was a need to include a floating action button (FAB) on some screens (destinations) in the app?

Scaffold includes support for a FAB, and will manage it's display in conjunction with snackbars, bottom nav bars, etc. The display state of the FAB could probably be managed in the NiaAppState class, and triggered based on the current destination of the NavController. It might function similar to how it manages the display state of the TopAppBar based on the current destination (if it's a TopLevelDestination, show the TopAppBar).

But I'm less certain how the FAB's onClick action would be handled? That might be significantly different depending on the screen that is being displayed. In some cases, it might just be a simple call to the navcontroller to navigate to a (child) destination. But for another screen (destination), it might need to trigger the display of a bottom sheet with content specific to the screen being displayed (and with Material3, there is currently no integration between modal bottomsheets and the navigation components).

So while the display state of the FAB seems pretty straight forward (it's a component in the NiaApp, driven by the current state of the NavController, so the NiaAppState should manage its display state), handling FAB clicks seems less obvious. It's almost like you'd need to pass the click event down the composable tree for the screen composable to handle (and that's not good in a Unidirectional Data Flow architecture. Events don't flow down, they flow up).

I'm wondering how a FAB might be handled in an architecture like this?