Referencing pre-populated templates, lazy loading into the DOM Tree

If the content of a template is embedded inside a template tag already (as part of the original server-rendered payload), but you want to be able to import a clone using the same syntax, you can do the following:


`html

...


`html

`

Note that there is no href, so this will do nothing more than activate the content.

I would not expect this kind of template to be present in the opening index.html (else why not just add the tags directly to the head tag?), but rather, from imported templates, which have dependencies.

Ok, I could see it in a standalone html file/stream also, if that file intends to be used both as a standalone web page, and as an embedded template in other web pages.

The id is optional, but, because there's no href, if the template will appear in multiple downloads (despite templ-mount's minimal efforts at de-dup), then providing the id will help templ-mount to avoid unnecessarily cluttering the head tag with duplicate script / style / link tags.

Disallowing activating content [TODO]

Allowing HTML references to load JS dependencies could be considered dangerous if the site the HTML is coming from is not very trustworthy, and/or appropriate CSP rules are not in place.

Investigations are underway to support the same kind of sandboxing supported natively by iFrames.

Snipping

If the html file / html stream being imported contains at least two instances of the following "magic string":

`html

`

then templ-mount can be made to only import the content between the first two such strings. This helps allow an html file / stream to serve both as a standalone web page, but also as a template that could be used as an embedded snippet of HTML. (JQuery's load function supports something similar).

At the top of this document, we mentioned the desire to allow servers to send content down in the native format that the browser will consume. This snipping solution goes against that strategy a bit, in the sense that here we are suggesting doing some string manipulation of the content. But most server-side solutions can easily snip out content in a similar way to what we are doing above. But if server-side solutions aren't available, you can snip out the main content thusly:

`html

`

$3

The left hand side and right hand side of the snipping can be specified:

`html

`

Changing parameters via href attribute of template or via href property

An iFrame allows you to change the src attribute, and the contents inside get replaced, rather than appended to. That is now supported, both as an attribute and as a property.

Dehydrating server-rendered content [TODO, tentative]

Defining a Web Component using templ-mount [untested idea]

Suppose you are developing a web component used to help illustrate the sequence of moves behind a chess match between Kasparov and Deep Blue.

You first create a template for a chess board.

I've taken an average of the number of lines of custom JavaScript needed to create these boards: 0. Okay, the first example is all HTML, but it uses a js-based web-component, css-doodle, for fancier effects, though. Having the browser natively support HTML with dependencies seems to be beyond anyone's wildest dreams currently. Just not technically feasible, we are told. Anyway...

We know exactly where the chess pieces will be when the game starts, so we don't really need fancy JS in our web component for that, just the html for the board, as shown in the code-pens.

The web component's JS will only be used to transform the html of the original board into different variations, depending on what moves are made. The JS is used only for the subsequent boards, in other words.

Unfortunately, the browser vendors have not been very kind to HTML-first solutions, which this screams for (as do many of the award-winning code-pens).

Suppose we stipulate that referencing a web component must consist of a single reference. The most natural thing for a web component like this would be for that initial definition to be in an HTML file, which can immediately display the original board, and which would then download the JS in preparation for the second board. But browser vendors aren't looking out for people like Tiny Tim, so we must make the web component load JS first. At least I don't see a way to make this HTML first, as it ought to be, with existing standards.

In order to provide the quickest visual, our web component, chess-board.js (say) can do the following:

Server-render the original chessboard inside a templ-mount tag. Use https://github.com/bahrus/nomodule

`html

...



...

`
myHeavyLifting.js gets a reference to the template via:

`JavaScript
const scriptTag = window['2071aa02-e277-47f7-882a-a5a7c6218d4d'];
const templMount = scriptTag.previousElementSibling;
if(templMount.loaded){
define();
}else{
templMount.addEventListener('load', e => define());
}
class Chessboard extends HTMLElement{
...
this[shadowRoot].appendChild(templMount.template);
}
...
function define(){
templMount.switchTo('chess-board');
customElements.define('chess-board', Chessboard);
}

`

switchTo deletes the innerHTML inside templ-mount, and inserts

What we need is a way of "flipping" a DOM element into a custom element

`html




`
$ npm install
$ npm run serve
`

Testing

`
$ npm run test
``