How to show AlertDialogs from Component?

[ScottPierce]

What's the best way to show a Jetpack Compose AlertDialog from a Component?

[arkivanov]

I would say it should be part of the state, just like any other view. Let me know if you need an example.

[arkivanov]

Both state-based and event-based might be valid approaches. There were some discussions about it in the Slack, the general attitude is to use state.

[moffpage]

That's actually a topic I haven't found an answer to by myself. Konstantin @terrakok had another point, which I agreed to at some point, but I don't actually see the difference in changing state if we push a child or display a modal (maybe). It's one of the moments when you want to be opinionated on something but you actually shouldn't be cause there (I think so, do you?) isn't much difference between those approaches

[arkivanov]

Definitely, but this particular question is about showin dialogs in Jetpack Compose. In this UI framework everything is state, including popups, alerts, etc. Even if you produce an event like ShowDialog, it still should change a state at the end. Same is valid for other declarative UI frameworks, like SwiftUI.

Regarding imperative UI frameworks. Event based dialogs might be a valid point, depending on circumstances. My personal opinion here is to use state as well. Because state is controlled to be consistent, and so you won't show multiple dialogs at the same time, you won't miss the dialog if the app is in background, or in an invalid state (no UI attached), etc. It requires more code for sure, which is the price for consistency and safety.

[moffpage]

I'm all here for consistency and safety! Thanks for your attention, I might change my mind after more investigation. I must elaborate into SwiftUI more, currently digging into Jetpack Compose more, although I love iOS development as much as Android development (or rather KMM development :DD) but so far in Compose I've seen using callbacks as being an advised way to handle events, but if you have more than 3 onCallback parameters, it's gonna start to get messy so I was thinking that having an events flow / stream isn't the wrong way (I'm not saying it's clearly wrong, you get it). And yeah, I don't think the "imperative" way differs a lot here from Compose

[arkivanov]

In declarative UI frameworks events (or callbacks) are going upstream, the state goes downstream. So usually you raise a property in the state and the dialog displays. Then the dialog fires a callback, which dismisses the property in the state and the dialog closes in response to the state change.

The way how you organise callbacks does not really matter. There are 3 common was:

1. Separate functions (lambdas) per each event
2. Group all callbacks into a class and pass the class instead (class MyEvents(val onCloseClicked: () -> Unit)
3. Define sealed class MyEvent and pass a single callback.

[plusmobileapps]

Not sure how complicated you were trying to get with the AlertDialog, but if it is simple with just a title, body, and a couple of actions such as cancel or okay I might just handle that directly in the view layer and not overcomplicate your components. That was a suggestion someone had for me when I was messing around with the Flutter bloc architecture.

If you are having a more complicated dialog, then I might do something similar to this master/detail question I had asked and instead create your own DialogComponent that is a property in the component you are trying to show it from.

[moffpage]

This. Displaying alert dialogs shouldn't probably be a router responsibility