I really like this approach. It is very natural for modal dialogs to be things that you await. I have used it in various projects in the past.
The main downside is if you need to affect the dialog from "outside". For example data that refreshes and needs to update the form (although in most cases a changing form is an anti-pattern anyways). But also any form of dynamically updating data (a clock) or lazy loading (maybe for a dropdown that depends on others) you are going to want a full UI library rather than a one-shot declarative form.
When I used this I had a separate call to create the dialog and await the result. This way there is a handle you can use to update the data if you need to. But even then if you are using React it probably doesn't integrate as cleanly as a "regular" component would.
But still, I think in most cases this is what you need and the easiest way to get it. I wouldn't take a more complicated approach until you need to.
I really like this approach. It is very natural for modal dialogs to be things that you await. I have used it in various projects in the past.
The main downside is if you need to affect the dialog from "outside". For example data that refreshes and needs to update the form (although in most cases a changing form is an anti-pattern anyways). But also any form of dynamically updating data (a clock) or lazy loading (maybe for a dropdown that depends on others) you are going to want a full UI library rather than a one-shot declarative form.
When I used this I had a separate call to create the dialog and await the result. This way there is a handle you can use to update the data if you need to. But even then if you are using React it probably doesn't integrate as cleanly as a "regular" component would.
But still, I think in most cases this is what you need and the easiest way to get it. I wouldn't take a more complicated approach until you need to.
Treating a dialog like an awaitable prompt is the kind of API that feels obvious in hindsight.