```FloatingActionButton( text = "aa", elev...
# compose
c
Copy code
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
b
what if you extract the snackbar to a composable func?
a
Where would you expect that snackbar to appear in your UI?
a
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.
a
A pattern you might be looking for instead:
Copy code
var snackbarMessage by +state<String?> { null }
// ...
FloatingActionButton(
  // ...
  onClick = { snackbarMessage = "dasf" }
)
// ...
if (snackbarMessage != null) {
  Snackbar(text = snackbarMessage)
}
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.
a
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?
a
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
but whether or not that encourages some broken abstractions is an open question 🙂
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
or in other words, I'm not sure making them easy to launch from really anywhere is necessarily a feature
especially not when it's already easy to show them from a known, controlled scope in response to app state, just like everything else
c
Copy code
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?
m
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.
a
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.
m
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 🙂