Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

idea: declarative markup for manipulating a shadow root's host #876

Closed
trusktr opened this issue May 14, 2020 · 1 comment
Closed

idea: declarative markup for manipulating a shadow root's host #876

trusktr opened this issue May 14, 2020 · 1 comment

Comments

@trusktr
Copy link

trusktr commented May 14, 2020

Some custom elements use tools like html`` template tag functions, or JSX, or etc, internally to make declarative modification to their internal shadow DOM.

But when it comes to modifying things on the host element, the element has to contain code like

if (this.authenticating) this.classList.add('authenticating')
else this.classList.remove('authenticating')

(ignore that this modifies the external state, and that the :--state feature will be better for this)

It might be convenient if instead the element implementation could achieve this declaratively, within the same markup that it already has.

So, similar to how CSS has a :host selector to target the host from the ShadowRoot, the DOM could have a <host> element to manipulate a ShadowRoot's host from markup.

With this feature, the custom element implementation could remove the above imperative code, and write something like the following (assume some JSX implementation takes care of the reactive updates):

@reactive authenticating = false

constructor() {
  super()
  this.attachShadow({mode: 'open'}).append(
    <host class={this.authenticating ? "authenticating" : ""}>
      <div>This content was already defined before.</div>
    </host>
  )

  // later something changes the value of this.authenticating
}

The <host> element would mirror any attributes to this instance's attributes. I'm not sure about attributeChangedCallback. Maybe it is skipped for such updates?

The <host> renders as if with a permanent display: contents CSS property, and it must be a direct child of the ShadowRoot (or else it does nothing, or perhaps an error is thrown), and there can be only one (or else it uses the first one, or perhaps an error is thrown).

I'm not sure if it is worth it. I thought I'd jot this idea down when it occurred to me.

@trusktr
Copy link
Author

trusktr commented May 14, 2020

Maybe the :--state feature will satisfy the use cases. Plus in the case where I thought I could benefit from this, I was setting a class on the host element just so that I could style it with :host in the CSS.

But in hind-site, I can achieve the same thing with an internal <div> in the ShadowRoot, and I can even set the :host style to display: contents to render the ShadowRoot's content in place of the host, without affecting the public interface. I can even assign that div as part="root" to give users styling access.

I'll just close this, as the alternative to the situation I had is better because it keeps the outside clean (and :--state will be nice for the purpose of the outside user styling the host).

@trusktr trusktr closed this as completed May 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant