How to model one shot operations in circuit state

[omkar-tenkale]

Support I want to show a toast after api call is complete.
Should it go like this:

1. Presenter updates states with toast = "Changes Saved!"
2. UI checks and shows the toast
3. UI sends toast shown event
4. Presenter updates toast = null

or is there a better way

[ZacSweers]

This is a good use case for Overlays.

Side note - please use discussions for questions like this. Went ahead and moved this and your other question here.

[iruizmar]

Can you elaborate on how to use Overlays for this?
I'm trying to display a simple Material 3 snackbar, which should only be visible for a short amount of time and only one should be visible at a time (this is the work SnackbarHost does). It's not a dialog or something the user should interact with.
Thanks!

[saurabharora90]

Right now I have been exploring using Kotlin Channel for it. I have added a Channel to the UiState, to which the presenter sends the one off events and the UI collects these events as a flow and responds to them accordingly (show a Snackbar if needed). Early days but it seems to be working well

[ZacSweers]

A non-interactable overlay could just return Unit when it's done displaying whatever it's showing. Snackbars are inherently interactable though, as they can be dismissed by the user.

[diousk]

@ZacSweers I'd like to know what is your opinion about resolving this kind of operations/events generated from presenter in Circuit.

Let's say, for example, a UI screen have 10 different kinds of dialogs to be shown at some time after user interact with UI or after network calls to show the results.

Should the State class be like:

data class State(
  val showDialog1: Boolean = false,
  val showDialog2: Boolean = false,
  val showDialog3: Boolean = false,
  // ...
  val showDialog10: Boolean = false,
): CircuitUiState

@Composable
fun UiScreen(state: State) {
    if (state.showDialog1) {...}
    if (state.showDialog2) {...}
    // ...
}

And what if there are more one-time UI widget need to be shown like snackbar or toast mentioned in this discussion?

IMHO, it becomes cumbersome and less maintainable.

What do you think?

[ZacSweers]

I think the reasonable thing to do would be to abstract the dialog construction out of the state into something concrete and easier to maintain. Or further decompose your state into substates. Not terribly different than how it would conceivably be handled in any other arch, where you generally want to avoid state stuffing like this.