When is emitReadyEvent needed?

Forge macros have an optional emitReadyEvent property:

This enables Confluence or other consumers, such as our PDF export service, to reliably detect when macros are fully loaded

Outside of exports of UI Kit macros (is that possible?), does that event serve any purpose? What is meant by “Confluence or other consumers” ?

1 Like

I have basically the same question.

I have a macro with body that renders the result of a calculation. The Word Export of the page will always render the original macro body, while the PDF Export will always render the content generated by the macro. So the Word Export is broken, the PDF Export is as intended.

It makes no difference if I add the code as shown in the example for emitReadyEvent, add a attribute, or do not emit the event at all.

Are there any Forge examples that show, how the use of this feature is intended? Would this feature fix the issue with the Word Export?

Non Atlassian here, and I agree the documentation is very light. We tested view.emitReadyEvent() internally, and found that it helps the PDF export finish much faster. I think it is a flag for the background PDF renderer to know the macro is finished loading, rather than waiting for a some timeout.

Exporting a PDF page in confluence with 3 custom UI forge macros ( no export or adfExport functions defined ).

  • without emitReadyEvent - ~100 seconds
  • with emitReadyEvent - ~20 seconds

Chris

1 Like

Hi Chris,
Thank you for your reply!

I do not see any performance improvements when I run my code exporting PDF. It is about 17 seconds with our without the emitReadyEvent callled. And the Word Export is never correct.

Now I wonder, if may code is correctly using the emitReadyEvent feature. I am very new to Forge and React. So I may be missing some basic concepts.

I have the emitsReadyEvent: true in my manifest with the macro definition. My code is like this, which is - at least to my limited knowledge - quite similar to the example found at https://developer.atlassian.com/platform/forge/apis-reference/ui-api-bridge/view/#emitreadyevent):

const [data, setData] = useState();
useEffect(() => {
  const loadData = async () => {
    invoke('getText', {example: 'my-invoke-variable'}).then(setData);
    await view.emitReadyEvent();
  };

  loadData();
}, [context]);

if (show()) {
  return data ?
    <>
      <Text>ok {data}!</Text>
    </>
    :
    <>
      <Text>Pending ...</Text>
    </>;
}
return (<>
</>);

But does this not emit the even prior to the end of the response generation?

Some AI proposed the following code where the event is signaled by an attribute with the generated code:

if (!config.hide || “off” === (config.hide)) {
return data ?
<Fragment emitReadyEvent={true}>
ok {data}!
:
<> Pending … </>; }
return (<> </>);

But I have not found that in the documentation so it may be a hallucination?

So I probably using the emitReadyEvent wrong? Could you share the part of your code that works?

Cheers,
Robert

Hi, we are not using React for this custom UI, so this may be of limited use. The code snippet is very simple and called as the last item after the page rendering is complete:

import * as Bridge from '@forge/bridge'; 

async function render() {
  try {
    ...
  }
  catch {
  } 
  finally {
    // notify renderer for PDF export
    await Bridge.view.emitReadyEvent();
  }
}

Maybe somebody from Atlassian can chime in?

2 Likes

Hi Chris,
Thank you for your reply!

It seems to me that you create the response and just before it is returned emit the event in the finally block. This helps a lot since I can discard the “attribute stuff”. I’ll try this and check, it it makes any difference for my “Word Export” problem …

Thank you for sharing!

If there is information from the Atlassian Team, I’d be happy to have further information on this topic.

Cheers,
Robert

Just a short follow up in case someone is as new to Forge as I am:

  • It took me quite some time to learn that the emitReadEvent fails when in the tunnel. Otherwise the solution presented by Chris works like a charm!
  • The “Word Export” still does not work. The issue here is probably somewhere else, since it works for “PDF Export”.
  • The emitReadyEvent also does not prevent the body from being rendered (that is why I looked into this). It is a feature to improve performance (again see Chris’ post for figures) for the export (as advertised in the docs).