Are there any plans to offer a proper “Modal Dialog” module (with custom UI support) in Forge? In Connect it was possible to register a dialog as a standalone module and then open this dialog from any other screen. That had the advantage that it didn’t matter where the dialog was opened from, the dialog always covered the whole screen (with the dialog blanket or the dialog itself).
Currently any modal dialog opened from a custom UI will not be able to do that, because the custom UI is limited to the bounds of the iframe that it is in.
Use cases for this that we have found so far:
A custom UI in a confluence:spacePage that opens an Atlaskit ModalDialog will work but will be very ugly because the dialog blanket will not extend outside of the iframe given, so the Confluence navigation, header, etc… will not be covered by it.
Opening a modal dialog via a button in a confluence:contentBylineItem is only possible via UIkit for the same reasons because a custom UI dialog would always open “inside” the inline dialog provided by the byline item.
Mixing UIs written in UIkit and UIs using custom UI is not really possible. Sometimes it would be easier to write a single dialog in UIkit and open it from a custom UI page or the other way around.
I guess this would require two things to be implemented: being able to define a modal dialog as a module and then a way to call this module from another module (custom or UIkit).
Thanks for the feedback! Opening dynamic modals in custom UI is something we are looking at but still working on prioritising. To help us prioritise this against other custom UI features, do you feel this limitation is a blocker for your app? For example could you work around this through a SPA spacePage that doesn’t use a modal or through using a larger viewportSize with contentBylineItem?
Hey, good to know that you are already looking at it.
For us it’s not really a hard/technical blocker, we have already worked around most of these issues. I think it’s more about the end-user experience, since the workarounds we used (or the ones you mentioned) are not always very user friendly. Or the workaround might mean that the UI behaves a little different compared to how Confluence/Jira apps would typically behave.
I understand that things like that are probably not the first priority for Forge development right now since there are workarounds. But since Forge apps can be released to the marketplace now/soon it would also be nice to also get some focus on things like that that make the end user experience a bit nicer.
Our Plugin (Epic Sum Up) is blocked to migrate to Forge Custom UI without this feature. In our Use case we have a web panel module and want to open a Dialog to do some configuration for this issue or view a detailed table with more information)
For your use cases, would you require the standalone modal to submit data back to the parent iframe? Or would it be enough just to have the parent know when the modal was closed.
I our use case I think we don’t necessarily need to submit data back. But there are some situations where it would be helpful to be able to submit some data back to the parent. What comes to mind would be for example status flags to indicate to the parent if they need to reload their data after the modal is closed. In that example if the parent only knows that the modal was closed it would have to reload its data every time, so not great but also not terrible.
Passing data back to the iFrame where the modal was opened is crucial for us, as we would like to exclude configuration screens into these modals. The configuration payload needs to get processed in the parent iFrame after closing.
We would really like to have this capability as a lack of it would push us to implement ugly/slow/unsafe solutions (persisting the data from the modal to Storage Api and get it back in parent).
@nhur
In the first step it would be enough for us if we just get a trigger back to know if the dialog was closed. We use it to open a configuration dialog from a web panel element and want to reload the panel when the dialog is closed.
With the ability to submit data back to the parent we could improve the behaviour so that it only reloads the panel if anything was changed
