Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTML Include Plugin #788

Closed
1 of 5 tasks
thescientist13 opened this issue Nov 3, 2021 · 0 comments · Fixed by #712
Closed
1 of 5 tasks

HTML Include Plugin #788

thescientist13 opened this issue Nov 3, 2021 · 0 comments · Fixed by #712
Assignees
Labels
feature New feature or request Plugins Greenwood Plugins RFC Proposal and changes to workflows, architecture, APIs, etc SSR v0.19.0

Comments

@thescientist13
Copy link
Member

thescientist13 commented Nov 3, 2021

Type of Change

  • New Feature Request
  • Documentation / Website
  • Improvement / Suggestion
  • Bug
  • Other (please clarify below)

Summary

In the spirit of the since abandoned HTML Imports spec that was originally part of the init Web Components "feature suite", and given the renewed interest in bringing it back, I thought it might be nice to bring this feature to Greenwood, in a more static context, as opposed to something that would happen purely at runtime. Effectively, this proposal / plugin would
would take the HTML include spec and realize it as more a build time templating system for HTML. The goal here is to enable developers the ability to ship more static HTML while allowing the authoring context to be JavaScript and leveraging standard semantics and web expectations.
. 💚

Note: I think if you want this feature in its most strictest sense of the word, I would recommend the custom element, which provides a runtime implementation of this as a Web Component.

Some of the work has already been spiked in #712 and so this issue will aim to formally bring it to live. 🙌

Details

I see two initial flavors of supporting this out of the gate that I would feel comfortable supporting and maintaining as a plugin and would provide HTML and JS based implementations.

It should be noted that this plugin would more or less be another way to achieve what the static optimization setting already does.

<link> Tag (HTML only)

The simplest flavor would follow the spec more closely and I think primarily address the use case of where you have static HTML that you want to reuse across your pages, like a global header or footer.

So given a snippet of HTML, e.g.

<!-- src/includes/header.html -->
<style>
  header h1.my-include {
    text-align: center;
    color: red;
  }
</style>

<header class="my-include">
  <h1>Welcome to my website!<h1>
</header> 

In a page template, you could then do this

<html>

  <body>
    <!-- the location can be anywhere in the workspace, I just chose to call it includes -->
    <!-- rel and href attributes would be required -->
    <link rel="html" href="/includes/header.html"></link>

    <h2>Hello 👋</h2>
  
  </body>

<html>

And Greenwood would statically generate this

<html>

  <body>
    <style>
      header h1.my-include {
        text-align: center;
        color: red;
      }
    </style>

    <header class="my-include">
      <h1>Welcome to my website!<h1>
    </header> 

    <h2>Hello 👋</h2>
  
  </body>

<html>

Custom Element (JavaScript)

For more advanced use cases where customization of the output may need to be done on a case by case basis, the other flavor would be a more JavaScript / web components flavor, allowing developers to return functions for generating markup and data and then Greenwood will build the HTML for them on the fly. This effectively aims to fill the gap where just static HTML alone would not be sufficient enough.

So using the Greenwood footer as an example, that displays the project version based on reading the contents of a package.json file, let's create a JS file that exports two functions; getTemplate and getData

// src/components/footer/footer.js
const getTemplate = async (data) => {
  return `
    <app-footer>
      <style>
        footer {
          grid-area: footer;
        }
        ...
      </style>

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

const getData = async () => {
  const version = require('../../package.json').version;

  return { version };
};

module.exports = {
  getTemplate,
  getData
}; 

In a page template, you could then do this

<html>

  <body>
    <h2>Hello 👋</h2>

    <app-footer src="../components/footer/footer.js"></app-footer>  
  </body>

<html>

And Greenwood would statically generate this

<html>

  <body>
    <h2>Hello 👋</h2>

    <app-footer>
      <style>
        footer {
          grid-area: footer;
        }
      </style>

      <footer class="footer">
        <h4>
          <a href="/">Greenwood v0.19.0-alpha.2</a> <span class="separator"></span> <a href="https://www.netlify.com/">This site is powered by Netlify</a>
        </h4>
      </footer>
    </app-footer>  
  </body>

<html>

IMO, think the JS flavor will really come to shine more when Greenwood adds support for #708 , and then you could use this for displaying user / session data, or serverlessly at the edge!

@thescientist13 thescientist13 added RFC Proposal and changes to workflows, architecture, APIs, etc Plugins Greenwood Plugins CLI feature New feature or request labels Nov 3, 2021
@thescientist13 thescientist13 self-assigned this Nov 3, 2021
@thescientist13 thescientist13 moved this from IN PROGRESS to IN REVIEW in 7 - SSR and External Data Sources Nov 4, 2021
@thescientist13 thescientist13 moved this from IN REVIEW to DONE in 7 - SSR and External Data Sources Nov 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request Plugins Greenwood Plugins RFC Proposal and changes to workflows, architecture, APIs, etc SSR v0.19.0
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

1 participant