```FloatingActionButton( text = "aa", elevation = 7.dp, textStyle = (+typography()).body...

# compose

[carbaj0]

FloatingActionButton(
    text = "aa",
    elevation = 7.dp,
    textStyle = (+typography()).body1.copy(color = Color.White),
    onClick = { Snackbar(text = "dsaf") }
)

java.lang.IllegalStateException: Composition requires an active composition context

[Bruno_]

what if you extract the snackbar to a composable func?

[Adam Powell]

Where would you expect that snackbar to appear in your UI?

[alexsullivan114]

I think you may be conflating the old Snackbar.make API with a Snackbar composable, which you need to setup just like any other composable.

[Adam Powell]

A pattern you might be looking for instead:

var snackbarMessage by +state<String?> { null }
// ...
FloatingActionButton(
  // ...
  onClick = { snackbarMessage = "dasf" }
)
// ...
if (snackbarMessage != null) {
  Snackbar(text = snackbarMessage)
}

[Adam Powell]

in the above, the message to be shown (or if there is a message at all, by way of nullability) is state, not an event. Events modify state, and composition reflects state.

[alexsullivan114]

I think it does bring up an interesting question though - Snackbar and Toast have very unique APIs to make them easy to launch from really anywhere. Are there any plans to offer similar APIs for their replacement composables?

[Adam Powell]

given a structure like the above, you could imagine storing a queue of messages in an Ambient and enqueue new messages to show with it from further down the hierarchy

[Adam Powell]

but whether or not that encourages some broken abstractions is an open question 🙂

[Adam Powell]

the shape of the toast and snackbar APIs had to make some tradeoffs that I don't think match the same cost/benefit in compose when controlling the scope of things is so much easier

[Adam Powell]

or in other words, I'm not sure making them easy to launch from really anywhere is necessarily a feature

[Adam Powell]

especially not when it's already easy to show them from a known, controlled scope in response to app state, just like everything else

[carbaj0]

Snackbars inform users of a process that an app has performed or will perform. They appear temporarily, towards the bottom of the screen. They shouldn't interrupt the user experience, and they don't require user input to disappear.

Do I have to handle the time that is shown on the screen, out the Snackbar component?

[matvei]

That's a good question indeed. For now -- "yes", as we don't have any of these mechanics.

Worth to note that we have already an ongoing discussion on how to make Snackbar usable and provide solid API shape, that will feel natural to Compose and to any architecture you're using it with.

[alexsullivan114]

Fwiw, in RN they just expose the imperative APIs we've used before (which can be quite awkward since it doesn't fit in with the declarative flow). Flutter appears to also expose an imperative flow, though you need to find a Scaffold to do so.

[matvei]

Yep. All you mentioned is why we're trying to make it right in Compose. Imperative API easy to implement and easy to reason about for people new to Compose, but it 100% doesn't fit any declarative proper architecture where you want to lift this state up to business logic. That's why so many people complain about Toast and Snackbar nowadays and there a lot of broken usages of those 🙂