feat: send render data to the iframe

[liady]

This PR adds the prop iframeRenderData to <UIResourceRenderer />'s htmlProps:

<UIResourceRenderer 
  resource={resource}
  htmlProps={{
    iframeRenderData: { customCss: ... }
  }}
/>

If it exists:

1. A query param waitForRenderData will be added to the iframe's src - so that the embedded content can decide to wait for this data before rendering or showing the content.
2. The data will be sent to the iframe in two ways:
   1. After the iframe's onLoad event - a message of type ui-lifecycle-iframe-render-data and the payload of the renderData will be sent to the iframe
   2. If the iframe will send a message with typeui-lifecycle-iframe-ready - the same message as in 2.1 will be sent back.

This double mechanism is meant to ensure that the onLoad message won't be lost.

A possible iframe code might be:

const shouldWaitForData = new URLSearchParams(location.search).get('waitForRenderData') == 'true'

if (shouldWaitForData) {
  window.addEventListener("message", (event) => {
    if(event.data.type == 'ui-lifecycle-iframe-render-data') {
      const { customCss } = event.data.payload.renderData
      // inject customCss
      // show content
    }
   });
  window.parent.postMessage({type: 'ui-lifecycle-iframe-ready'}, '*')
} else {
  // immediately show content
}

[cloudflare-workers-and-pages]

Deploying mcp-ui with    Cloudflare Pages

Latest commit:	b80c92f
Status:	✅  Deploy successful!
Preview URL:	https://fa1a2975.mcp-ui.pages.dev
Branch Preview URL:	https://feat-frame-render-data.mcp-ui.pages.dev

View logs

[Copilot]

Pull Request Overview

This PR adds support for passing render data to iframes through a new iframeRenderData prop on the HTMLResourceRenderer component. The feature enables parent applications to provide initialization data to sandboxed iframe content via a dual-mechanism message system.

• Adds iframeRenderData prop to allow passing data to iframe content during initialization
• Implements dual-delivery mechanism using both iframe onLoad event and iframe readiness messaging
• Adds URL parameter waitForRenderData=true to signal iframe content to wait for data

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
sdks/typescript/server/src/index.ts	Exports new message types and URL parameter constants for iframe lifecycle
sdks/typescript/client/src/components/HTMLResourceRenderer.tsx	Core implementation of iframe render data functionality with dual-delivery mechanism
sdks/typescript/client/src/components/__tests__/HTMLResourceRenderer.test.tsx	Unit tests verifying URL parameter handling for render data scenarios
docs/src/guide/client/resource-renderer.md	Documentation explaining the new feature with usage examples

Comments suppressed due to low confidence (1)

sdks/typescript/client/src/components/HTMLResourceRenderer.tsx:134

• The handleMessage function references iframeRenderData but it's not included in the useEffect dependency array. This could cause the effect to use stale values of iframeRenderData.

        sandbox="allow-scripts"

[idosal]

Can we add tests for the lifecycle (e.g., assert a postMessage is sent when the iframe loads ot a message is received by the parent)?

[jonathanhefner]

@liady

This double mechanism is meant to ensure that the onLoad message won't be lost.

I was curious: does this refer to the parent window missing the iframe's load event, or the iframe missing the ui-lifecycle-iframe-render-data message right after it loads?

For either case, is it more precautionary or are there concrete scenarios to be aware of?

[idosal]

@liady

This double mechanism is meant to ensure that the onLoad message won't be lost.

I was curious: does this refer to the parent window missing the iframe's load event, or the iframe missing the ui-lifecycle-iframe-render-data message right after it loads?

For either case, is it more precautionary or are there concrete scenarios to be aware of?

@jonathanhefner the iframe missing the event. The widget might take a while to add the listener. We saw it in the wild.
There's actually another message type to explicitly call render data later in the lifecycle (see #111).