DCE Demo Discussions: Tram-Deco by Jesse Jurman

[Westbrook]

As presented on 18 March to the WCCG, tram-deco is a proposed approach to declarative custom elements by @JRJurman.

Links to slides TK as available.

Further discussion and questions below.

[JRJurman]

Slides - https://whimsical.com/dce-and-dsd-8QrsieiVLhEmmyAejnug78
Tram-Deco - https://github.com/Tram-One/tram-deco

[JRJurman]

Going through the comments in the chat, and will add new posts now 😄

[JRJurman]

Will go through the questions in the google doc shortly! Feel free to post whatever questions as well!

[JRJurman]

@sorvell How is that better than just authoring the class?

I answered this on the call, but the big benefit is that we might not need JS for the most simple "I want a shadow root with content, slots, and scoped styles". If users have JS, this implementation has a way to progressively support that (with the script tags that have lifecycle methods), but isn't required to get that first bit of rendering.

[JRJurman]

@justinfagnani how do you do imports, etc

I didn't go into it here, but I think if we have a way to import HTML and parse that, that would be all that's required - this probably isn't 1-to-1 with any module implementation, rather just "can we add and parse HTML". Tram-Deco supports this today with a dedicated class call TramDeco.import('./spoiler-tag.html');, but all that does under the hood is load the template and run a Document.parseHTMLUnsafe

[JRJurman]

To clarify, I'm not opposed to an HTML Module interface, it's just not something that has been totally fleshed out in this implementation 😅 - I actually think having a way to author and share external component definitions is super important, just not something I have super strong insight into or hardened opinions on.

[JRJurman]

@michaelwarren1106 i think i'm with justin and steve and just one script with the class in it is the easiest? you can do imports and callbacks like normal etc
@justinfagnani I think it'd be more minimal to define a class though - you wouldn't need all these lifecycle attributes... and it'd be a normal module. The attributes seem to imply that there's a generated class behind the scenes and that the scripts aren't executes immediately like all other script tags

There's definitely a "how do I import other JS, how do I handle some callback attributes, etc..." that isn't totally fleshed out here, and would be solved by injecting a class definition here. I'm not sure I love having to intermingle the DCE and class definitions together, but I'm not totally opposed to it. I still think the ergonomics of per-lifecycle method script tags is nicer, and classes can be a large hurdle for non-JS developers getting into web components, but that's totally a biased take 😄

[matthewp]

If it's a module it's going to cause FOUC. How do you prevent that?

[JRJurman]

@matthewp - just to clarify, are you asking about the presented implementation, or the suggestion to have an exported module from a script tag?

In the existing Tram-Deco implementation, we can process the HTML template definition before the rest of the document, and I think the general hope would be that the script tags with lifecycle methods could be processed after-the-fact. Not sure implementation-wise what that would actually look like (sans javascript and more baked into the browser).

[JRJurman]

@sorvell Without declarative tempating, it's pretty unsatisfying imo.

In part, I'm leaning hard on whatever the DOM Parts initiative comes up with. While reactivity with attribute templating would be really awesome, I feel like that's a separate initiative that doesn't have to come before DCE (and certainly shouldn't be exclusive to DCE).

[JRJurman]

@michaelwarren1106 how would public component methods be defined? like MyDCEModal.show()

I haven't thought through that, but I don't think there's a reason that a script tag couldn't have a custom lifecycle method (maybe that's a strong enough reason to have a more generic method="whatever" attribute).

<template definitions>
  <my-dce-modal>
    <template shadowrootmode="open">
      <dialog>My Dialog</dialog>
    </template>
    <script method="show">
      this.shadowRoot.querySelector('dialog').show()
    </script>
  </my-dce-modal>
</template>

[JRJurman]

@michaelwarren1106 if you did two definitions, how would you do two <script connectedCallback> and delineate which connectedCallback impl goes with which CE in the template?

In the template each element definition contains its own lifecycle method scripts, e.g.

<template definitions>
  <my-foo>
    <script connectedcallback>
      console.log('my-foo created', this)
    </script>
  </my-foo>

  <my-bar>
    <script connectedcallback>
      console.log('my-bar created', this)
    </script>
  </my-bar>
</template>

This depends on the template parsing to know "associate the script with its parent element", which I hope is trivial, but admittedly, I don't know if we have a pattern of that in the standards.

[JRJurman]

@EisenbergEffect This is nice and terse, and simple. I like that. BUT I have the concern that the design is not flexible enough or forward compatible with handling the breadth of use cases. Examples are things like light dom rendering, controlling define and tag name, declaring non lifecycle methods, fields, properties. Scoped elements, etc.

Yeah, for sure - I think this represents the most simple first-step forward that I've been experimenting with, and all the feedback here is super valuable to expanding this POC out.

I'd maybe push back on the light dom rendering and anything that isn't already possible in the Web Components API, since I would like this to be 1-to-1 with what's possible in class based definitions, but if we think that's something that could be possible in class based definitions, then I'd totally concede that we need a way to do it here as well.

[JRJurman]

How to nest <template definitions> elements for scoped registrations?

I guess there is a larger question about where we allow definition templates, and how composable they can / should be. I haven't totally thought through that here.

In Tram-Deco you specifically call out which templates to process, and maybe we could mimic that here (since creating custom registries requires JS anyways). E.g. in the example below, we intentionally omit the definitions attribute, so that we can consume it in a JS-defined scoped registry.

<template id="myCustomElements">
  <callout-alert>
    <!-- element definition stuff -->
  </callout-alert>
</template>

<script>
  myCustomElementRegistry.parse(myCustomElements)
</script>

[JRJurman]

Intersection of definitions and shadowrootmode attributes on <template> tag?

I believe this is the same question that was asked live, but in general, I think this question is about what the expected behavior is if a template has both of these attributes.

We have some pattern in the standards (specifically looking at script elements) where attributes are mutually exclusive, and I think this is a similar situation, where you can only have one or the other.

[JRJurman]

Duplicate children does what?

I believe this question was asked live, and was specifically asking what if you define multiple elements with the same name.

I think we would want to emit some sort of warning, I don't imagine this problem is unique to this solution, or even DCE (although we have better options for end users to catch errors in JS-land than we do in HTML).

The current implementation in Tram-Deco uses customElements.define, so in that case the first instance wins out, and other copies fail.

[JRJurman]

What do you get from customElements.get()?

Similar to the above question about duplicate children, there's probably a generic question on how these DCE implementations interact with customElements that's not unique to this DCE solution.

In Tram-Deco this creates a class, but understandably that feels weird if JS isn't a requirement for these to process as expected.

[JRJurman]

DSD interaction
Kind of nice implementation for the way that it aligns with capabilities around DSD
HOWEVER, DSD and custom elements are technically intersected…

There was a general comment live about this coupling the implementation of Declarative Shadow DOM to Custom Element definitions.

Luckily the Tram-Deco solution doesn't expect anything special from DSD, rather it consumes it sorta as-is - since we don't have any attribute templates or anything like that, we copy the created shadow DOM with all of it's attributes and clone it on construction.

I think that this won't need any modifications on the existing DSD API. This does tie the custom element definition to look for DSD and pick it up for Component creation. Potentially we could just pick up any non-script elements instead (if they are DSD, copy that, if they are light DOM elements, copy that) - but that feels very non-web-component API.

As it is, I believe that you can create a web component with a DSD template inside it, and it automatically knows to use that template, so this feels similar to that interface.

[JRJurman]

If you have <div> under <template definitions> what happens?

The current implementation in Tram-Deco blows up with whatever error you would get from customElements.define('div', class extends HTMLElement {} ).

I think this problem isn't unique to this implementation, although there may be a special frustration if you can't include other kinds of DOM (like comments) in the element definition template. I'm pretty sure the check I have in Tram-Deco only looks for children elements though, so that should be relatively safe.

I think, like the duplicate elements issues, we need some way to safely warn / blow up on the user when they would try to define an invalid element (whether that's because it is already defined, doesn't have hyphens, or whatever).

[JRJurman]

@justinfagnani What is the benefit of the <template definitions> element?

• The content of <template> is supposed to be inert until cloned (<template shadowrootmode> stretches this).
• <template definitions> means that individual definition elements can't be query selected, etc., Makes introspection and meta-programming harder.
• Can we just add a new element, like <element>?

The goal here is finding the absolute shortest path to DCE, so I think leaning on the existing pattern for templates with attributes feels fine.

It is possible to introspect the elements that have been defined using template.content.children, however I'd probably wager that any complex meta-programming might be better served with class-based implementations 🤔

If you have examples of advance introspection you are doing in any DCE solution, would be happy to investigate here and see if there is a solution here as well!

[JRJurman]

@justinfagnani Why use a <template shadowrootmode> as the element template?

• <template shadowrootmode> creates a shadow root right where it's used.
• A component definition can use just a regular <template> which is cloned into the shadow root.

The idea here is to tap into the existing supported API for DSD. That means also consuming attributes like delegatesfocus or any new attributes we might see added to DSD! We could make an assumption about shadowrootmode, but it's probably safer to require it, and have it match 1-to-1 with DSD outside a component definition.