Introduce API to register templates for encapsulating entities (and with optional templating logic)

[cvan]

In 0.1.0 we had the concept of templates:

<template is="a-template"
          element="a-image"
          width="1.75"
          height="1.75"
          opacity="1.0"
          src="">
  <a-entity geometry="primitive: plane;
                      width: ${width};
                      height: ${height}"
            material="shader: flat;
                      src: url(${src});
                      opacity: ${opacity};
                      side: double;
                      transparent: true">
  </a-entity>
</template>

Because our primary use case has been to extend entities for common use cases, we agreed to rethink "templates" (formerly known as "mixins" - not to be confused with <a-mixin>s, heh). And by rethink I mean remove until we've proven all the interesting use cases (and there certainly are some).

So instead of providing a declarative means of encapsulating one or many entities and exposing it as a custom element by some name (via the element attribute) through a <template is="a-template">, we've decided to use "primitives" as a way of extending entities.

The "old" templates are now not a high priority, but they're something we should not forget about and revisit some time.

If we don't want to enable devs to define templates from inline HTML (or HTML imports), we could introduce a JS API à la registerComponent for registering templates. For inspiration, check out X-Tag's xtag.register (go to https://x-tag.github.io/ and check out the examples in Docs > Content is King).

---

Relevant: PR #883

[cvan]

If we decide to reintroduce declarative templates and allow them to be defined from HTML imports, we ought to revisit #579 and resolve that issue. If templates do get resurrected but in the form of a JS API, that's a non issue.

[ngokevin]

Good sticky note, but not actionable at the moment/not an issue.

[cvan]

I think we need a discussion about which types of bugs to file and which to keep in our heads. I file issues like these so that we can track our thoughts and point contributors to them.

[ngokevin]

I just take things case-by-case. We file whatever and then we decide what to do with them.

For this issue, I felt it was ok to close since it was just a note that summed up to something like "we are removing templates, maybe sometime we can look at them later", which I'm predicting will be quite a ways out and our expectations will have changed.

[cvan]

if we set the proper expectations for what's a valid issue to file, I'll know what I should bother filing - and what I should not bother filing and just make a personal mental note of.

[ngokevin]

i just say file whatever seems right and we'll handle it. but we can chat more later

[RangerMauve]

What if you went more with the way SVG does <defs>. Specify entities with an ID in some specific area, (maybe in assets?) and then have something like <a-use href="someid"/> to use them.

https://developer.mozilla.org/en-US/docs/Web/SVG/Element/use

[ngokevin]

Would also be good to think what an A-Frame templating layer would provide over existing templating solutions.

[RangerMauve]

Also, I think "templates" and "mixins" seem like they could be merged into one concept since they're doing similar things. Not sure if that's on topic for the thread, though.

[ngokevin]

I did have that idea earlier that you could add child entities to mixins, and those entities would get mixed into the scene when used. It's not template registration, but i like that.

[RangerMauve]

I actually like that idea more than templates, even. Only complaint is that it seems that this could all be accomplished with components somehow, rather than having both mixins and components as basic composable units in the markup.

[ngokevin]

Not necessarily. While components change the appearance/behavior of an entity, mixins aim to make component property definitions reusable across the scene as a whole.

[ngokevin]

Doing a lot of experiments with templating at https://github.com/ngokevin/aframe-templating-examples

I'm converging to a flexible template component which I think has an elegant and powerful API with more predictability the previous a-template/a-root implementations.

[RangerMauve]

Nice! I've been thinking of implementing a server that does server-side rendering of scenes for the purposes of a puzzle game of sorts. Though I guess I was second-guessing that lately because of the issue of losing VR on navigation. :/

[ngokevin]

@dmarcos and I talked and agreed any implementation would be too opinionated. It functions very well as a third-party library for now, and we can promote these elsewhere:

#1384