[w3c/webcomponents] [Template Instantiation] Layering and additional use cases (#747)

At the face-to-face in Tokyo, @justinfagnani, @domenic and I shared a few of our goals related to the [Template Instantiation proposal](https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md). I would like to document some of the use cases we imagined to facilitate continued discussion on the topic.

We have begun to think of this feature in terms of three levels (low to high), so the use cases have been organized into levels below. Feedback is anticipated and welcome here, but even if the layering is contentious we hope that the use cases can be considered on their own.

We intend to break this issue out into narrower use-case-specific issues after we have received feedback on this overview.

**Please note** that the use cases described below are intended to be additive or adaptive to what can already be found in the [Template Instantiation proposal](https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md). 

**Please also note** that code examples are intended to suggest the capabilities, _not_ the shape of the API.

## Level 1

We see the `TemplatePart` as the vital primitive at the core of Template Instantiation. It enables us to expressively update discrete spots in the DOM tree as state changes. At the lowest level, we would like to:

 1. Create `TemplatePart`s
 2. (Dis)associate `TemplatePart`s with nodes or node ranges in a tree
    - **Example:** `NodePart.attach(parts, parentNode, startNode, endNode);`
    - **Note:** When attached, a `NodePart` should subsume pre-existing nodes into its list of current nodes
 3. Access a list of `TemplatePart`s associated with the cloned content of an `HTMLTemplateElement`
    - **Example:** `const { content, parts } = template.cloneWithParts(...)`

## Level 2

Level 2 incorporates the concepts of the `TemplateProcessor` and `TemplateInstance`. In addition to what the current proposal describes, we would like to:

 1. Imperatively produce a `TemplateInstance` from an `HTMLTemplateElement` and a `TemplateProcessor`
 2. Perform some `HTMLTemplateElement`-related “preparation” work one time per `HTMLTemplateElement` per `TemplateProcessor`
 3. “Lazily” produce the DOM content associated with a hierarchy of `TemplateInstance`s

## Level 3

At the highest level we wield Template Instantiation from markup. The current proposal satisfies our perceived use cases at this level, assuming it also satisfies the use cases we described at levels 1 and 2. The topical use cases at this level including the desire to:

 1. Declare an `HTMLTemplateElement` and its associated `TemplatePart`s in HTML with a default syntax
 2. Create a `TemplateInstance` with a standardized `TemplateProcessor` that is built into the browser


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/747