I've seen people treat modals (with the legacy vie...
# compose
c
I've seen people treat modals (with the legacy view system) as either state or an event. With compose, I'm more inclined to consider the fact that a modal is showing as part of my state for the screen. In my case I'd have an AAC ViewModel with something like
errorModalShowing: Boolean
Not sure if I'm missing some kind of best practice here, but let's take a quick poll! Do you treat modals as: 1️⃣ State 2️⃣ Event
2️⃣ 1
1️⃣ 20
b
IMO, you will typically have events AND state changes when dealing with a Modal. If you are adhering to a Uni-Directional Data Flow pattern in which State flows down to UI, UI is updated from state, and events are triggered from UI and flow up causing changes to State … Then the “proper” way to handle a modal becomes clearer. A modal is a piece of UI, not really any different than a block of Text or a Button, etc. As such it should be rendered when some State model (Flowing down from the ViewModel) has a particular value. Then another part of the UI (Say a button) will trigger an event that will flow up (to the ViewModel) which will in turn cause an update to the State Model to indicate that the modal should be shown. The state model change flows down to the UI, and the UI is updated to display the modal. If you are treating a modal as an event (when X happens, show a modal), then you aren’t really adhering to the Unidirectional Data Flow pattern, because a modal is just a piece of UI, and UI should only be rendered based on State (and/or changes to state). Not that you HAVE to follow the Unidirectional pattern, but A. The Compose team pushes that pattern VERY hard, and B. My experience has always been (even in the old View system) that the pattern makes code MUCH easier to understand, reason about, and maintain, particularly in teams where there is more than one person working on it.
c
Event vs state was a question for how to communicate fr the VM to the composable. I understand events are needed to go from modal back to VM.