Post Editor: Update EmbedView to use createRef instead of string refs

[tyxla]

This PR is a follow-up to a recommendation made in a previous PR: #38608 (comment) by @jsnajdr.

Changes proposed in this Pull Request

• Post Editor: Update EmbedView to use createRef instead of string refs

Testing instructions

• Tinker with embeds in the classic Calypso post editor and verify they still work well and unchanged.

[matticbot]

Test live: https://calypso.live/?branch=update/tinymce-embed-view-string-refs

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

Sections (~9 bytes added 📈 [gzipped])

name         parsed_size           gzip_size
post-editor        -23 B  (-0.0%)       +9 B  (+0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[jsnajdr]

this.iframe is always an object, for example, { current: null }. What you really want to check for is ! this.iframe.current.

[jsnajdr]

Check for this.iframe.current instead.

[jsnajdr]

componentDidMount should also call constrainEmbedDimensions() here.

Previously, there was a setState( { wrapper } ) call that immediately triggered a second render. On that second render, componentDidUpdate was called with in turn called constrainEmbedDimensions.

But now, when this setState() is gone, there can be just one initial render with no further updates.

[jsnajdr]

I'm afraid this setState() call, which forces a two pass render, might be necessary. It first renders the container <div> and then, in second pass, creates the <iframe>. Instead of rendering <div><iframe></div> in one pass.

When iframe is being created in DOM, it might go through some weird intermediate state where iframe.contentDocument or iframe.contentWindow are null. And they are initialized only a moment later, when some async process inside the browser finishes.

If iframe.contentDocument is null, our code can either crash, or fail to set the content HTML.

I've been debugging this a few months ago inside the components/web-preview component and still don't understand it.

Here's the relevant definition from the spec: https://html.spec.whatwg.org/multipage/iframe-embed-object.html#dom-iframe-contentwindow

I don't know what "nested browsing context" means and when it exists or not.

[tyxla]

I'm not sure either 🤷 I prefer closing this one to avoid introducing subtle bugs. Let's revisit in the future 👍

[tyxla]

Closing, will revisit in the future.