Maybe I'm missing something, but why is Dialog a Composable and not implemented in a similar way as ...

# compose-desktop

[ckloss]

Maybe I'm missing something, but why is Dialog a Composable and not implemented in a similar way as Window? Don't you think that in a desktop application it would make more sense for it to behave like Window? This way, it would be easier to use at an event like onClick for example.

[Zach Klippenstein (he/him) [MOD]]

I was wondering the opposite: why doesn't Window use a declarative API like everything else in Compose? I assumed it was just an early prototype to get things working, like the mouse events stuff.

I think imperative window control in general is a step backwards. I've seen lots of bugs and unpredictable behavior come out of it, and was really excited that dialogs were declarative in Compose. We've done a good bit of work to make modals declarative in our apps and it's much safer once you get used to it.

[ckloss]

Thanks for your answer. I agree with you about the benefits of a declarative API. I just can't see why instantiating something modal would be unsafe. After all, being a new instance,  it is not a part of the declarative content of the parent window and it is tedious and verbose to use it in a declarative way. You have to explicitly manage a whole state to control the dialog visibility that otherwise would be implicit in an imperative way. 

All being said, I was just wondering why Dialog was not imperative as Window. Maybe I can't see yet the whole picture of this new declarative world and I’m missing something but it is what it is and I can live with it being declarative...

By the way, congratulations on JetBrains compose. I’m loving it.

[Zach Klippenstein (he/him) [MOD]]

Bumping this thread in case it got lost in the scrollback. @olonho any insights here?

[olonho]

Yes, we’re evaluating such APIs, @Andrew Rudenko [JB] will have more context here some time soon.