I’m confused as to why Compose’s dialog popup uses...

# compose

[Chachako]

I’m confused as to why Compose’s dialog popup uses declarative to complicate things. Creating a dialog just by imperative like Flutter is great, for scenarios with lots of dialogs I would need to maintain a bunch of states to handle it which sometimes usually makes things messy, another good way might be to handle it by MVI but that’s not the best either, I even created an imperative dialog to solve this problem. Is there any reason to create a dialog by declarative instead of imperative? 😢

[agrosner]

state management. if you just imperatively launch it, then you may display it more than once in a loop by accident. mixing the two worlds would seem a bit strange for UI elements

[agrosner]

(IMO)

[agrosner]

you woild have to maintain state hook of the shown dialog and then remember to close it manualy if your state changes. with compose, you can surround that in a simple if statement on a state value

[Albert Chang]

Because compose is a declarative UI framework. Why do you use a declarative UI framework?

[Casey Brooks]

In the imperative world, there is only ever 1 way to display that dialog. But in the state-driven world, a big feature is that there are many ways to build out the state that would result in a particular boolean value being true to display the dialog.

You could use the simple by remember { mutableStateOf(false) } right at the dialog, but you may also want to lift that state to the parent composable. You may wish to manage it from the root of the screen through the MVI pattern, or even listen to a websocket to know when to show/hide the dialog. If the dialog was displayed imperatively, then these more complex use-cases would end up managing what the state of the dialog should be, but also needing to have intimate knowledge of the current UI state to know how to synchronize the two.

Or, you just let Compose do the synchronization of state to UI elements, and you just declare that you want a dialog to be visible or not. Which is what it we’ve got currently.

[Casey Brooks]

It’s much easier to take a declarative UI element and wrap it in an imperative API. But it’s much more difficult to take an imperative element, and make it work declaratively.