Re: [w3c/webcomponents] Repurposing the is="" attribute to allow multiple behaviors to be attached to a given element (#662)

Another idea could be that the Element reference passed into a component's constructor could actually be a `Proxy` to the Element, which forbids the component from writing to the element. The component could read properties or call methods, or even set certain properties that are part of the element's API (f.e. setting `.value` of an `input` element), but the Proxy would prevent components from creating new properties. This might prevent some much clashing, though components could still clash if they both set `.value` of an `input` for example.

---

Or maybe there could be a way for a component to statically define which properties it will control, and the first component to be added which controls such properties takes precedence. f.e.

```
class SomeComponent {
  static controlledProperties = ['value']
  static elementTypes = ['input'] // limit the component to `input` elements.

  // ...
}
```

Then this component would control the value of `value` in whatever way it wants. If a second component was added that also wanted to control the same property, it could perhaps receive an error whenever it tries to do so, and act accordingly. f.e.

```
class ComponentTwo {
  static controlledProperties = ['value']
  static elementTypes = ['input'] // limit the component to `input` elements.

    // ... in some method ...
    try { this.el.value = "blah" } catch(error) {
      // ... react accordingly, error might have useful info, f.e.
      // "Component "foo" already manipulates "value" property."...
    }
}
```

Would some sort of conflict-avoidance feature like that be too complicated of a to add to such a spec if it were spec'd?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/662#issuecomment-327370806