Expose lifecycle of AMP components to enable constructing them dynamically

[westonruter]

Feature Request: Expose the the lifecycle of AMP components so that they can be embedded in a React context, where dynamic changes to an AMP component’s attribute propagate the expected changes to the component’s shadow DOM.

Problem: The inability to use AMP components in dynamically-created DOM trees severely limits the ability to create content with AMP components in React-based editors such as the new WordPress’ Gutenberg editor. In a nutshell, AMP components cannot be used reliably in Gutenberg’s editor blocks. This limitation can be mitigated in the case of AMP components that have HTML equivalents, but there is no mitigation for components without HTML equivalence, such as the amp-carousel and those in the AMP Story format.

This is related to #15583: Facilitate using AMP as component library (without intending AMP validity).

---

We are developing an AMP Stories editor for WordPress (ampproject/amp-wp#968). It is built with the AMP Plugin for WordPress, and it is built on WordPress’ next-generation editor: Gutenberg. This new editor is built with Rect at its core, and the main premise of its design is the creation and manipulation of content around the notion of encapsulated units called blocks. The aim of Gutenberg is to provide a visual editing experience, where blocks can be directly manipulated and modified, and where there is an immediate preview of how the block will appear on the frontend.

As part of the AMP plugin for WordPress, AMP-specific Gutenberg blocks have been developed, such as those encapsulating amp-mathml, amp-time-ago, and amp-fit-text. However, such integration of AMP components into Gutenberg blocks has been hampered due to one important limitation: AMP components cannot be reliably used inside of React components, which is how Gutenberg blocks are built.

Some AMP components do work in the context of React components. For example, a simple AMP component like amp-mathml does work in a React context (video demo). This is either because in this example the amp-mathml component is rebuilt entirely after an edit, or because the component’s DOM is simple, having a single iframe child.

Other AMP components do not work in the context of React components. For example, using the amp-fit-text component in React does not yield the expected results (video demo). In this case, when the amp-fit-text component's height, min-font-size, and max-font-size attributes are modified, the corresponding changes are not passed along to the shadow DOM. See ampproject/amp-wp#1342 in the AMP Plugin repository for details on experimenting with these two components. It's expected that blocks with more complicated nested DOM structures, like the amp-carousel, will not work properly in a React context either.

[amedina]

/cc @cramforce @rudygalfi @ericlindley-g @pbakaus @vinaymahag

[dreamofabear]

IIUC this is basically @dvoytenko's proposal for AMP components without AMP runtime.

@westonruter Note that while we do have a rough idea for how to generally support this, it will probably be a long time until it's available in production (several quarters). Until then, you may be able to get AMP components to work by destroying/recreating them on mutation and/or manually invoking lifecycle methods e.g. buildCallback() and layoutCallback().

If destroy/recreate doesn't work and there's a small list of buggy components, we can probably start working on per-component support. E.g. using mutation observer in amp-fit-text to listen for attribute changes.

[dreamofabear]

@westonruter Going to merge this with #15583. Thanks for writing up the detailed FR.