The former, because IMO a dialog being visible is always a part of the app's state.

Reframe events and db.

I'll take the opposite view. Usually with an R/Atom. Come to think of it, I think it is because it feels odd to me to put a state like that in a db. I prefer the DB to stay focused on the main app data.

App db for me. I see modals as app state

A generic dialog/modal component with no state and only arguments so that I can decided if I want to drive it with re-frame state or reagent state from the parent component. Both have pros/cons.

from past experience my preference is to store it in (with a clear distinction of purpose) or have it be a calculation based off of values in the app-db, for data driven visibility. simplifies things like having QA store the entire app-db as an edn file, for Devs to load locally and review exactly what they were experiencing. or ease interop with some analytics frameworks. still possible to do without storing everything in the app-db, but a bit more work to pull off. like mentioned, pros & cons to both paths, depends on the scenario at hand.