Add the f-template component which can interpret a text binding and convert it to a ViewTemplate

[janechu]

Pull Request

📖 Description

This is some initial work to convert declarative HTML into a ViewTemplate.

👩‍💻 Reviewer Notes

Some of this is preliminary work to get a workflow established for creation of aspect bindings and other requirements for the declarative HTML. This work also exposes the fastElementRegistry as well as exposing some global values to trigger instantiated components to update their internal definitions after a new template has been applied.

✅ Checklist

General

• I have included a change request file using $ npm run change
• I have added tests for my changes.
• I have tested my changes.
• I have updated the project documentation to reflect my changes.
• I have read the CONTRIBUTING documentation and followed the standards for this project.

⏭ Next Steps

• Adding attribute bindings
• Adding logic for common directives such as when

[KingOfTac]

This looks good to me, but I have one question. If f-template expects a name so that it can build a custom element from the provided template then would it make more sense to rename to f-element instead? I can see value in having both a f-element component for creating custom elements and a f-template component for just rendering a ViewTemplate without the need to attach it to a custom element. If I'm mistaken on this then feel free to ignore.

[janechu]

This looks good to me, but I have one question. If f-template expects a name so that it can build a custom element from the provided template then would it make more sense to rename to f-element instead? I can see value in having both a f-element component for creating custom elements and a f-template component for just rendering a ViewTemplate without the need to attach it to a custom element. If I'm mistaken on this then feel free to ignore.

Interesting point, I'm not sure we would ever create a ViewTemplate without the intention of attaching it to a custom element, because what would you do with it? If we did we could leave the name attr off. I do see the issue with the duplicitious naming though, that has been brought up we basically have a template in a template, but that's only because we're leveraging how the browser works. I think there also might be some interesting ideas people are shopping around where it pertains to template parts, but then I think also at that point we just expand the logic for f-template.

Edit: Thinking on it a little further, we might have a secondary option of referencing other templates so you might have something like:

<f-template name="article">
    <h2>{{title}}</h2>
    <f-template part="content-body" content="{{content}}"></f-template>
</f-template>
<f-template name="card">
    <img src="{{imgsrc}}">
    <f-template part="content-body" content="{{content}}"></f-template>
    <a href="{{link}}">{{linktext}}</a>
</f-template>
<f-template id="content-body">
    <p>{{content}}</p>
</f-template>

[KingOfTac]

Edit: Thinking on it a little further, we might have a secondary option of referencing other templates

Yeah that's kind of what I was thinking. On its own f-template could just declaratively represent a ViewTemplate that can be composed into more complex things, much like how you can create ViewTemplates on their own today with the tagged templates to be composed into other templates/components.

I'm assuming the real, rendered output would just be the contents of the template with any bindings evaluated?

Edit: I have something similar to this already in another project for an island component, the main difference there is that it fetches the ViewTemplate from the server and replaces itself with the template contents at runtime rather than doing everything at build time but the underlying concept is pretty much the same.

[janechu]

I'm assuming the real, rendered output would just be the contents of the template with any bindings evaluated?

Yes exactly, an example of the rendered output can be seen in the binding.fixture.html, this is just the beginning where we implement the logic for a simple binding, more complex cases will be added to this one as we go. Things are still somewhat in flux though so it's a good time for feedback 😊.