Recently i’m implementing a dynamic form in macro config in Confluence Forge app and encountered a weird behaviour in macro config.
The columns select field options are retrieved via resolver function to fetch all the available property columns based on the Type field. The initial state of the columns is empty array (), this is why you would see No options at first.
After the resolver invocation has been executed in useEffect, the Columns select field has been filled up with the result from resolver.
However, when i try to select the next column, the macro config somehow reset the state to init state and the Columns select field became ‘No options’ again
Therefore, i would need to go through the fetching process again to fetch the available properties.
I would like to know is it an expected behaviour for macro config in forge? Seems like it impact the user experience where the user has to wait for the fetch for every option selection.
What do you have as the dependencies for the useEffect hook? Every time you select an option, you change the config, which rerenders the component. You might be able to keep it with the right dependencies or useMemo or something similar.
Hello,
We are using Custom UI and experiencing similar issue - when saving macro config in a Forge Confluence macro.
Steps to reproduce:
-
Open macro config dialog
-
Save config - code calls view.submit({ config }) - dialog is closed
-
Quickly (within ~1–2 seconds) click “Update page” in Confluence editor
Observed behavior:
The updated config is not persisted — the page is saved with the previous config values.
Code example:
view.submit({
config: {
hint,
text
}
}).then(res => {
console.log(`Submitted successfully response: ${JSON.stringify(res)}`);
}
From debugging it looks like the Promise returned by view.submit resolves before the config is actually applied to the editor state.
Expected behavior:
There should be a way to reliably know when config changes are fully applied and safe to publish, or view.submit should resolve only after the config is committed to the editor document.
Is this expected behavior, or is there a recommended way to handle this race condition?
