You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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>headerh1.my-include {
text-align: center;
color: red;
}
</style><headerclass="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 --><linkrel="html" href="/includes/header.html"></link><h2>Hello 👋</h2></body><html>
And Greenwood would statically generate this
<html><body><style>headerh1.my-include {
text-align: center;
color: red;
}
</style><headerclass="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.jsconstgetTemplate=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">◈</span> <a href="https://www.netlify.com/">This site is powered by Netlify</a> </h4> </footer> </app-footer> `;};constgetData=async()=>{constversion=require('../../package.json').version;return{ version };};module.exports={
getTemplate,
getData
};
<html><body><h2>Hello 👋</h2><app-footer><style>footer {
grid-area: footer;
}
</style><footerclass="footer"><h4><ahref="/">Greenwood v0.19.0-alpha.2</a><spanclass="separator">◈</span><ahref="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!
The text was updated successfully, but these errors were encountered:
Type of Change
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.. 💚
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.
<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.
In a page template, you could then do this
And Greenwood would statically generate this
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
export
s two functions;getTemplate
andgetData
In a page template, you could then do this
And Greenwood would statically generate this
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!
The text was updated successfully, but these errors were encountered: