Side Effect Free Templates and Pages (No JS Web Components)

[thescientist13]

Overview

Had this idea a while ago thought I had captured / mentioned it in either #354 or #305 but effectively, somewhat like through our optimization settings, would nice to see if there's a way to detect if code / components included in a template are "side effect" free, thus they would be marked as static automatically and would never be shipped to the user.

Basically, this is intending to enhance the more fine grained, user controlled experience of how to manage templates and payloads if you didn't want to involve any form of SSR where Greenwood would try and detect some of the optimization options for you. it's not clear how useful this strategy is if SSR for native HTMLElement works out really well, but for anyone wanting to keep it super simple while still wanting to use Web Components + pre-rendering to build their sites / apps, this might be really nice to have.

Example

Take for instance these two components from the Greenwood website, the footer and the banner.

Footer

import { css, html, LitElement, unsafeCSS } from 'lit-element';
import json from '../../package.json?type=json';
import footerCss from './footer.css?type=css';

class FooterComponent extends LitElement {

  static get styles() {
    return css`
      ${unsafeCSS(footerCss)}
    `;
  }

  render() {
    const { version } = json;

    return html`
      <footer class="footer">
        <h4>
          <a href="/">Greenwood v${version}</a> <span class="separator">&#9672</span> <a href="https://www.netlify.com/">This site is powered by Netlify</a>
        </h4>
      </footer>
    `;
  }
}

customElements.define('app-footer', FooterComponent);

Banner

import { LitElement } from 'lit-element';
.
.
.

class Banner extends LitElement {
  constructor() {
    super();

    this.currentProjectIndex = 0;
    this.animateState = 'on';
    this.projectTypes = [
      'blog',
      'portfolio',
      'website',
      'web app',
      'marketing site',
      'small business'
    ];
  }

  .
  .
  .

  cycleProjectTypes() {
    this.currentProjectIndex = this.currentProjectIndex += 1;

    if (this.currentProjectIndex >= this.projectTypes.length) {
      this.currentProjectIndex = 0;
    }
  }

  firstUpdated() {
    setInterval(() => {
      this.animateState = 'off';
      this.update();

      setTimeout(() => {
        this.cycleProjectTypes();
        this.animateState = 'on';
        this.update();
      }, 1000);
    }, 3000);
  }

  render() {
    const currentProjectType = this.projectTypes[this.currentProjectIndex];

    return html`
      <div class='banner'>
        ...
        
        <h3>The static site generator for your. . . <br /><span class="${this.animateState}">${currentProjectType}.</span></h3>

        ...
      </div>
    `;
  }
}

customElements.define('app-banner', Banner);

The footer only needs to run once to generate HTML that can be prerendered and then be static forever, Greenwood might be able to use an AST to see if something not like setInterval exists, like in the banner.

So the outcome here would be:

• footer would be marked as static
• banner would be marked as default (since we need the JS for the cycle code, as could be inferred by setInterval usage

Caveats

I'm not actually the full scope of what would be considered not side effect free and / or how practical an endeaver this would be, but I don't mind exploring it for a little bit if folks would be interested. I'm hoping that SSR + Declarative Shadow DOM + defer will make for a really nice experience for both users and developers, so will be keen to measure against those efforts as well.

[thescientist13]

Actually, another way to think about this could be like in PHP where you can just include a file and everything just "comes in" e.g.

<?php include 'footer.php';?>

This is what I think the old HTML Import spec was trying to achieve, which now has more life to it maybe? But either through a spec or a plugin even, it would be great to make something like this possible, e.g.

<link rel="html" href="path/to/some/html"></link>

Or maybe we could do it more like a web component I guess, but just not sure how to "link" everything

<my-header>
  <link rel="html" src="path/to/some/html"></link>
</my-header>

<!-- or -->
<my-header data-gwd-src="path/to/some/html">
</my-header>

Both have some pros and cons

• First approach means we don't have to guess the custom element, we can just replace <link> with the contents of src
• Second approach looks a little cleaner

And for DX, we could make it so you could either use a JS or HTML file, as long it was just HTML that always came back, and then Greenwood could just straight up insert that into the DOM. without needing any JS at all for say something like a header or footer, even if it just needed JS at build time. 🙌

Some relevant issues to follow along with

• Client side include feature for HTML whatwg/html#2791
• HTML Modules WICG/webcomponents#645

[thescientist13]

Opened a PR to prototype this @ #712

[thescientist13]

Another idea I had since statically analyzing a component may be brittle, is to use a resize observer that could be used a hydration mechanism, so only include the component definition when it actually scrolls into view. This would be dependent on initial HTML being able to completely bootstrap the browser, including styles, but if an initial HTML payload can be delivered first, maybe that would be enough?

That said, would the UI get too janky if WC were just "popping" into place as you scrolled? I suppose a health viewport bottom padding would be needed, but it would be great to somehow "intercept" customElements.define so registration would only need to happen JIT... 💡 🤔

When using Lit, I think this could be a good use case for a ReactiveController.