Simplify interaction between canvas and editor

[Janpot]

Simplifying the awkward interaction with the canvas iframe. Moving all logic that requires access to the dom inside the frame to avoid imperatively querying the dom methods in favor for using react refs.

Ultimately the goal is to try and reduce amount of renders for #853 and if that's impossible, lay the basis for extracting a common API to build both preview windows on top of

@apedroferreira we could think a bit more about the architecture for the future.

• Can we move to a model where we avoid portaling the overlay? instead use the bridge to communicate with the app canvas. e.g. create API's like https://chromedevtools.github.io/devtools-protocol/tot/DOM/#method-highlightNode
• Would it be possible for such an API to be transferrable? So that we have more options in terms of passing events (window.top.postMessage) and rely less on the awkward handshake to set up the bridge.

[render]

Your Render PR Server URL is https://toolpad-pr-858.onrender.com.

Follow its progress at https://dashboard.render.com/web/srv-cc4aj25a499dfghg48k0.

[apedroferreira]

Simplifying the awkward interaction with the canvas iframe. Moving all logic that requires access to the dom inside the frame to avoid imperatively querying the dom methods in favor for using react refs.

Ultimately the goal is to try and reduce amount of renders for #853 and if that's impossible, lay the basis for extracting a common API to build both preview windows on top of

@apedroferreira we could think a bit more about the architecture for the future.

• Can we move to a model where we avoid portaling the overlay? instead use the bridge to communicate with the app canvas. e.g. create API's like https://chromedevtools.github.io/devtools-protocol/tot/DOM/#method-highlightNode
• Would it be possible for such an API to be transferrable? So that we have more options in terms of passing events (window.top.postMessage) and rely less on the awkward handshake to set up the bridge.

I might not 100% understand the solution we use for this problem and how we use the bridge, or what exactly causes the issue with multiple rerenders, so correct me if i say something wrong. But I understand that what these changes are doing is reducing interaction from the iframe with things outside of the iframe, by keeping as much logic as possible inside the iframe?

If the fact that we are portaling the overlay is adding to the rerendering problem, it should be possible for us to find a different way to make things work. Are you suggesting keeping the overlay outside the iframe, and sending something like events over the bridge to the iframe? Might be simpler and more intuitive than what we're doing right now.
Not sure what you mean by making the API "transferrable", is it something like what I described?

I'd have to try things out with the iframe to see how we could implement this in specific, but the general idea sounds worth exploring.

[apedroferreira]

I had some wrong assumptions in my previous comment, edited it now, hopefully it's better.

[Janpot]

I might not 100% understand the solution we use for this problem and how we use the bridge, or what exactly causes the issue with multiple rerenders, so correct me if i say something wrong. But I understand that what these changes are doing is reducing interaction from the iframe with things outside of the iframe, by keeping as much logic as possible inside the iframe?

the communication between host and iframe content currently happens through an object (the bridge) both realms hold a reference to. Setting up this object and making sure both realms are looking at the last correct instance is a bit of an awkward process. Also, a lot of the measuring (getPageViewState) is done by the host realm on a DOM node it queries in the iframe. Setting up this dom node and making sure it stays in sync is a bit awkward. This PR moves the measuring inside of the iframe so that we don't have to manage syncing this dom node as well as the bridge.