It's pretty common to have one Scaffold in MainApp which handles the SnackBarHost, and all requests ...

# compose-android

[bryankeltonadams]

It's pretty common to have one Scaffold in MainApp which handles the SnackBarHost, and all requests to show a snackbar on the snackbar host are drilled down through the navigation component to where it needs to show a snackbar. What's the consensus on Dialogs? Should Dialogs be handled by the Main App composable and it's stateholder/viewModel perhaps, or is this something that would make sense to be handled per Composable/Route?

[Stylianos Gakis]

I handle snackbars per screen too actually (only a handful use them) so I don't know about a consensus 😅
I suppose just do whatever feels right.
I also handle dialogs just per screen too, using a common composable function to ensure consistency in the design of course.

[FunkyMuse]

I'd avoid a global scaffold, it's better to create one component for the snackbar and reuse it in every screen you need it, same as a toolbar.
One global component which in this case seems to be the scaffold won't scale if many other parts try to control it.

The only usefulness I find for the scaffold is if i have a fab and needs to be positioned accordingly and/or docked.

[bryankeltonadams]

@FunkyMuse Now In Android in their sample project uses a global scaffold with only one snackbarhoststate and a showSnackBar lambda that is driven through the navigation architecture. How else do you handle a snackbar not disappearing when navigating throughout the app if you do it at the screen level? i.e. i login, show a success snackbar, and it disappears because now I'm showing the logged in screen instead.

[bryankeltonadams]

@Stylianos Gakis Do you run into issues where you snackbars disappear when navigating between screens?

[Stylianos Gakis]

Yeah they do, but as I said, I use those sparingly, and usually if the user has gone back (and therefore has exited that screen) they no longer care about what information it had to offer to them.

[Kevin Worth]

@Stylianos Gakis I don't think it's about whether it's there when you go back. More like you see the snackbar for only milliseconds because it goes away as soon as you navigate forward.

[FunkyMuse]

@bryankeltonadams that's one use case as well, it's a global slot for the snackbar host and you can dispatch events to it, that's how you can control it, but dispatching event from one screen might mean show from other hide etc...

[Stylianos Gakis]

In the screens where we show snackbars, going forward is not possible. The snackbar is shown when there’s an error in the stuff needed in order to go forward.
But again, maybe I shouldn’t be speaking here since we really only use them in a handful of places. If it’s a core part of the app maybe you can’t get away with per-screen implementation

If you do have a global one, I assume what you do is dispatch events into it, and it will internally have to queue them properly so that they don’t hide one another. But then if you send too many, you’ll end up waiting an odd number of time for all of them to come and show one by one.