Hey,
I tested the new feature for custom-ui apps in conjunction with Modal dialogs - and observed a strange behaviour in the Modal Dialog. But step-by-step.
So looks my simple Custom-UI app:
First I used a div-wrapper to the Modal-Dialog without any height css-parameter. So I received the following output when I activated the Modal-Dialog via the button:
Thanks for that @FranzBinder. We don’t really recommend using Atlaskit modals in Custom UI because they don’t really work very well in the context of an iframe generally.
However, we are still in the process of enabling these to be used in the Confluence macro module. I can let you know when that work is finished.
That said, the continuous size increase does seem to be undesired behaviour nonetheless. I’ll have a go at reproducing your issue, in the meantime, to see if there is a reasonable workaround.
You should be able to disable automatic resizing by adding a viewportSize property to your manifest for that module. If you already have defined a viewportSize for the module, then the issue is not related to automatic resizing.
I read the description for Custom-ui-bridge/modal but I’m a little bit confused how to use it. Do you have any real live example / instruction?
Additionaly I don’t understand the need to use the bridge for a modal dialog which is used on the Custom-UI / React side. The Atlaskit approach seems more logical for me
One more question: are there other Atlaskit elements which you don’t suggest?
Regarding viewportSize : I tested different sizes but I love the ability to show the whole content without scrollbars. Disabling automatic resizing is in this case not a good alternative.
@FranzBinder great question, I don’t know of any live code examples, but I can try explain usage in a bit more detail.
In your Custom UI app (not the modal), you will need to first instantiate the modal:
import { Modal } from '@forge/bridge';
const modal = new Modal({
resource: 'my-modal-resource',
onClose: (payload) => {
console.log('onClose called with', payload);
},
size: 'medium',
context: {
customKey: 'custom-value',
},
});
Then you can add modal.open() to the event handler for the button that opens the modal.
The modal itself must be defined as a Custom UI resource itself. You can either define a whole separate resource for it (the resource in the constructor of Modal refers to the resource’s key in the manifest), or you can use the context above to tell the Custom UI code to render a modal. E.g. you might pass in { isModal: true } to the context, and in the resource, you can use view.getContext() to render the modal UI or the app UI based on isModal.
In the modal UI, you can use view.close() to close the modal, and if you want, to send data back to your app to do something with it (defined in the onClose handler above).
Yeah, if the Atlaskit modal could work, that would definitely be the most sensible option. Unfortunately, features like modals and any kind of pop-up or drop-down don’t work very well with iframes. That’s why we’ve created this separate Custom UI modal feature, as a way to create a modal experience within the constraint of iframes.
Re: not wanting to use viewportSize. Understood, we are working towards making Custom UI modals available in macro. In the meantime, is it possible to workaround using a different UI experience (e.g. changing what is displayed in the app directly to show what was going to be in the modal)?
There are many reasons. The biggest one is that I’m using drop downs which does not work with connect or forge iframes (try positioning an atlaskit/select at the bottom of the frame with 10 options).
The safest approach for me is to get as big of a rendering area and for me to handle the rendering.
This is a bug in forge - which is going to make me have support costs.
@danielwester thanks for describing that. I can understand why that’s problematic.
I’ve tracked this feedback here: [FRGE-371] - Ecosystem Jira. I also left a comment on a potential solution, although it’s just me thinking out loud.