Hi there, we are trying to make a floatingActionButton to open a dialog on click. But as the onclick...

# compose

[Elias]

Hi there, we are trying to make a floatingActionButton to open a dialog on click. But as the onclick function is not annotated with @Compose, this does not seem to be possible. Does anyone know about the recommended approach to achieve this behaviour?

[allan.conda]

btw, what compose component do you use to show the dialog?

I’d just mutate the state for dialog visibility in this case

[Elias]

Thanks for answering. Yes we ended up just doing that, but it would feel more straightforward not needing a state for that.

We were using Scaffold.

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

If it were possible to open a dialog imperatively from a click handler, compose wouldn't really be a declarative framework anymore, and we'd be heading back to where we are today where it's harder to reason about complex UIs because you have to keep the state machine in your head to figure out what the code is doing, and they're harder to test because everything is based on side effects firing everywhere.

It definitely takes a bit of getting used to, but I really think forcing explicit state like this actually forces code to be cleaner, more readable, and more testable in the long run, especially for large apps.

[Elias]

I see your reasoning. But as I am strongly adverse to having a state, it doesn't really mix in my head. I can understand it in the case where you would completetly switch context. But in our case, where the simple thing we wanted to do was show a Dialog with a text input I cant see the issue.
I can however see the issue as there is no way for the compose crew to discriminate between the different use cases, it is probably best to do it this way.

[Elias]

Maybe I just have to let go of my state fobia.

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

The thing is, your app already has state – all apps are stateful. The real issue we’re talking about is where that state lives. If you think you don’t have state, that just means your state is being managed by someone else and hidden from you, and now you are responsible for keeping those separate state machines in sync manually by making the right imperative calls. There are multiple sources of truth.

E.g., by imperatively showing a dialog, you’re still updating some state somewhere to say a dialog is now showing. But because you don’t own that state yourself, you now have to also handle how to dismiss the dialog yourself. What happens if something happens that causes your app to navigate to an entirely different screen, and you forget to dismiss the dialog? What if you want to be notified when the dialog is showing or not, so you can update some UI on your main screen? You end up writing a bunch of code to synchronize the hidden system state machine with your own state machine(s). On the other hand, if you own the state about whether the dialog is showing, and just tell the system what that state is, there’s a single source of truth.

[Elias]

Thank you for taking the time to answer me! If you couldn't tell, I'm new to this. I appreciate the effort!

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

No worries, I hope that explanation makes sense!