search

Netflix / x-element

A dead simple starting point for custom elements.
Apache License 2.0
28 stars 12 forks source link

Allow extending `observedAttributes`. #84

Closed theengineear closed 2 years ago

theengineear commented 3 years ago

Super minor change, but we expect all observedAttributes to come from our statically-declared properties. Instead, we should assume that authors may want to observe additional attributes beyond what they declared in the properties block. That is, we should allow this:

static get observedAttributes() {
  return [...super.observedAttributes, 'some-other-thing'];
}
klebba commented 3 years ago

@theengineear why would they be disinclined to declare this in the property block? Can you include a material example? Not resisting the change per se but I don't yet follow when/why I would use this

theengineear commented 3 years ago

Why would they be disinclined to declare this in the property block?

Yah for sure. Here are a couple thoughts:

  1. A simple case. Say you wanted to simply watch changes to the "id" attribute. We both know that elements sync the content attribute with the IDL attribute so it could allow you to simply see when the "id" changes without needing to cause an update on the element.
  2. The case I ran into. I'm looking to work with Form-Associated Custom Elements which have a "form" content attribute which is set by the user and a "form" IDL attribute which is managed by something called the "ElementInternals" interface where you would "attachInternals()" and get access to some special intel about your element. It's pretty hard to essentially decouple the content attribute from the IDL attribute right now. This would help allow users to be in a more "manual" mode.
  3. Maybe the most convincing... I develop a fair amount of simple components without XElement, I find it frustrating that I cannot add additional logic to observedAttributes — we can append logic to connectedCallback, disconnectedCallback, attributeChangedCallback via super.*(), why not this one particular method? It just strikes me as an unnecessary restriction. That is, "I'm an expert — let me do the thing."

☝️ — Sorry, that got wordier than I intended! I hope these arguments are still readable! I'm also going to drop some additional thoughts in a note below (just want to keep ideas somewhat organized).

theengineear commented 3 years ago

AND, some other thoughts:

  1. In general, I think XElement doesn't let you get manual enough. Especially as I work more with Form-Associated Custom Elements, I find that I need fine-grained control over things. Anything from pass-through getters into the "ElementInternals" interface to manual timing of syncing properties/attributes.
  2. XElement currently doesn't let you handle nuanced relationships between content attributes and IDL attributes. Checkout the WHATWG spec for the input element! I don't know whether we should support such interfaces, but it's been on my mind lately.
klebba commented 2 years ago

Wew, I can't believe I left this hanging since May. I will admit I don't fully grok the technical problem, and a code level example would help, but I don't want to level more burden contextualizing this. You had me at "I can add behavior to the other standard methods, why not observedAttributes" — philosophically this is misaligned with the project, and we should get out of your way when possible.