RFC: Declarative host element

[nolanlawson]

Rendered

[nolanlawson]

Technically this in light DOM is not exactly the same as what you'd get with lwc:ref, since the former is the internal view of the component and the latter is the external view. But it's ~99% the same. You can do this.classList, this.children, this.setAttribute, etc., and it works as expected.

[jmsjtu]

ordering of changes made to <lwc:root>

Is this referring to the ordering of how classes, event handlers, etc. are applied from <lwc:root> to the host element?

versus elements inside of the template

Does this mean that there could be a difference in the order the classes, event handlers, etc are applied on the host vs to elements within the host?

[nolanlawson]

No, I didn't think of that. Updated! bbbc288

[jmsjtu]

Will this element be available for light DOM as well?

[nolanlawson]

Yes. Clarified: 815466f

[pmdartus]

I would go a step further and deprecate all APIs exposed on the LightningElement that are covered by this proposal.

The main motivation would be to remove those programmatic APIs on the engine server. Removing programmatic host element mutation would certainly greatly simplify the SSR logic and would enable us to get rid of some of the DOM APIs polyfills we have to maintain for SSR.

[nolanlawson]

To clarify, are you proposing that we remove all DOM-like APIs on the this exposed to component authors? E.g.:

renderedCallback() {
  console.log(this.children)
  console.log(this.getAttribute('class'))
  console.log(this.querySelector)
}

?

[pmdartus]

Yes, I was wondering if we should deprecate all those DOM-like APIs. That said there are some APIs like dispatchEvent that would certainly have to stay on the LightningElement prototype.

[nolanlawson]

My understanding was that, someday, we might converge the "bridge element" and "lightning element" classes. It would be a nice simplification from my POV if this just referenced the element (as it does in other web component frameworks like Lit). In that world, all of these APIs would "just work."

[pmdartus]

I was always under the impression that the long-term goal should be to merge the LightningElement instance with the host element.

But I am now questioning this, because of the tension it creates with SSR. In a world where we can achieve this merge. Does it mean that we would have to polyfill all the DOM APIs available on the host element to make LWC components compatible with SSR?

Something that I really about this proposal is that we provide a declarative alternative to those DOM APIs. Those APIs enable developers to write isomorphic components without having to worry about the environment they are running in. Another added benefit of this declarative approach is that it enables the LWC compiler to optimize the usage of those APIs.

This is just food for thought, I don't have yet a formal opinion on this.

[abdulsattar]

What about replacing the template tag with <lwc:root>?

e.g.

<lwc:root class="klass">
  <h1>regular elements</h1>
</lwc:root>

Of course, the regular <template> will still be supported.

[nolanlawson]

To me, this seems like too much of a drastic change to the existing system. Developers are very accustomed to putting <template> at the top.

It also raises questions of how we would need to support lwc:render-mode, lwc:preserve-comments, etc. on <lwc:root>. Whereas if the two are separated, then it's clear which directives apply to which tag.

[jhefferman-sfdc]

This sounds very good, ones that are important to us include aria-xyz, role, size, id