inheritance and dependencies?

[clshortfuse]

Hi :)

I was taking a look at the spec and was wondering how easily I could migrate my code to the spec should it land.

For example, with most my Web components I use a mixin pattern. It's pretty similar with how the behavior systems.

Some mixins are rather simple, but some can get complex and even chain. For example, I have:

• AriaReflectorMixin
• AriaToolbarMixin
• InputMixin
• ControlMixin
• FormAssociatedMixin
• KeyboardNavMixin
• TextFieldMixin
• ThemableMixin
• StateMixin
• ResizeObserverMixin

Each mixin takes a the custom element's class and extends it. It then goes to work. But some mixins will mixin another mixin before extending. For example, ControlMixin will mixin FormAssociatedMixin. InputMixin will mixin ControlMixin. That's pretty transitive. I imagine it's a matter of class ControlBehavior extends FormAssociatedBehavior.

But some mixins expect another mixin to have been applied first (dependencies). For example, my most complicated setup, I have three CustomElements:

• XInputElement
• XTextAreaElement
• XSelectElement

They all reference TextFieldMixin which serves as branching point for mixins. Both XTextAreaElement and XSelectElement will use the ControlMixin, but XInputElement will use the InputMixin. They each also have a host of other mixins (like StateMixin).

This is mostly dealing with component definition, though runtime behaviors would definitely help with a mixin I have called TooltipTriggerMixin which I just apply to IconButton by default. It's better if it's done at runtime for any component.

Question 1:

What happens if a redundant behavior is listed?

<x-custominput has="themable state input textfield resizeobserver">
<x-custominput has="themable state control input textfield resizeobserver">

Question 2:

Do behaviors load after or before an element is defined? (I assuming before, or else how would observedAttributes work.)

Question 3:

Can behaviors be defaulted for elements? (Can behaviors be used to simplify Web Component design/definition). Once a component is finalized with its behaviors, I don't expect authors to have to include them each time.

---

Thanks for sharing your work with the public. If you're interested in taking a look at the mixin structure I'm talking about, I added links above. (The .mixin() and .extend() are just aliases which I find help write more declaratively, but everything can be rewritten in class/extend structure).

[clshortfuse]

Oh, I just realized this is meant to be an alternative to Custom Elements, not in addition to Custom Elements. Though, I guess on a technical level, what you can do with a native element, you can do with a custom one.