More often than not, the dialog widget needs to load data from an API. That is, not all dialogs are composed of static HTML. They need data from the API to construct some of the elements using API data, such as
select element options.
Loading data from the API and building the resultant elements isn't the issue; we do this all the time. The challenge comes when we try to perform these activities within the dialog context. We don't necessarily want to display the dialog until the data has been loaded from the API, and the UI components used to display them inside the dialog components have been built. Ideally, we would block the dialog from displaying until the components displayed by the dialog are ready.
This is especially tricky with remote API functionally, where it is impossible to predict latency issues. Furthermore, the dialog may depend on more than one API call, each populating its own UI component in the dialog.