AMP components lack a template rendering solution

Background

amp-story creates some components with a lot of dynamic DOM that gets built manually or with an arbitrary single-render solution we call SimpleTemplates.

amp-lightbox-gallery runs into similar issues of manipulating/creating a lot of DOM manually.

This is problematic:

• Template rendering for amp-story is bloated: allocating memory for an arbitrary strings/object hierarchy and then recursively navigating it.

• Manually writing DOM manipulation, templating logic and arbitrary formats is productivity-prohibiting.

  Using innerHTML is fine for cases where the DOM content is static, but that can lead to changes to make the content dynamic. That’s a slippery slope into security holes. See #11633 for a nightmare PR.

• Other templating systems are used on AMP at the authorship level: mustache, JSX. These can benefit from a unified templating output for SSR, etc.

Goal

• Reduce the overhead of template rendering on amp-story and possibly other components.
• Define a single templating system to be used internally.
• Make AMP component rendering first-class to make AMP more “app-like”.

Proposal

• Implement a unified templating solution for AMP components to build/manipulate complex DOM, which gets compiled into a performant output.

  • The input language should be constant. Consider lit-html (easiest), handlebars, mustache, JSX, etc. The language should be statically analyzable, so the simpler the better (i.e. JSX is difficult to statically analyse due to its dynamic nature and use of JS syntax).

• The output performance can be improved over time:

  • We can easily output semi-dynamic templates into vanilla DOM transforms now if we do some refactoring of amp-story/amp-lightbox-gallery.

  • For complex components that manage a lot of state (i.e. amp-story) consider a more robust workflow like Svelte.

  • Output format can be leveraged in SSR by other components in AMP: authorship-level templating, etc

• Reduces code complexity: fewer instances of imperative manipulation, proprietarily described templates, etc.

/cc @jridgewell @kristoferbaxter @aghassemi @choumx

[alanorozco]

@kristoferbaxter sketched out a design that looks pretty great. Some additions/changes mine:

const MyTemplate = new Template(
   // Source is language-agnostic:
   `<div class="i-amphtml-my-component">
     Hello, <p ref="name">{{name}}</p>
   </div>`);

// Fields defined in instantiation will be used for render.
const template = new MyTemplate({name: 'Paco'});

// The template can be rendered into a container.
const {refNodes} = template.render(container);

// Elements marked as `ref` in the source template will be a vanilla-
// referenced as part of the rendering result.
const {name} = refNodes;

// ...which can then be imperatively manipulated.
name.innerText = 'Pedro';
setStyle(name, 'color', 'red');

// etc.

Assignment of MyTemplate then gets compiled into something like:

class MyTemplate {
  constructor(initialState) { /* ... */ }      
  
  render(container) {
     // ...
     // (Optimized DOM manipulations generated from source.)
     // ...
     return {
       rootNode,
       refNodes: {
         'name': /** @type {!Element} */ (elementCreatedByCompilerCode),
       }
     };
  }
}

What’s cool about this:

• we can explicitly set references to elements contained in the template to keep our current after-render logic, at no cost.
• we can expand further down the line (e.g. use JSX with the same API).
• output format can be generated from any source language

[alanorozco]

Thanks both for commenting, I think @kristoferbaxter tightened the loose ends.

/cc @cathyxz for amp-lightbox-gallery, @cvializ for amp-date-picker