Question: would it be useful to combine behaviour in a superclass?

[ErikOnBike]

Hi Cory and others,

First of all: big kudos to Cory and contributors. Shoelace is really nailing things! Love it.

I see a number of elements sharing similar behaviour. Not only SlInput and SlTextarea share common behaviour, but other elements like SlCheckbox and SlSwitch as well. Would it be useful to combine this in a class hierarchy? Maybe I missed the memo explaining why this can't be done. I think this would result in behaviour in a single place and prevent updating to take place in multiple locations. The following structure seems logical (from my point of view ;-)). It is not meant to be complete:

• SlFormControl
  • SlCheckControl
    • SlCheckbox
    • SlSwitch
  • SlTextControl
    • SlInput
    • SlTextArea

The SlFormControl has behaviour related to nameing, value, disabledness, requiredness and validity. It can receive and lose focus, it can report on validity and such. The SlCheckControl adds behavior for checkedness and can be clicked. The actual SlCheckbox adds behaviour for being indeterminate, while the SlSwitch does not add specific behaviour, other than the visual appearance. Likewise with SlTextContral and subclasses.

As an aside, this works for me. I'm building wrappers around the different elements and using the above structure allows me to have behaviour in a single place. Just wondering if this could be useful for Shoelace itself or whether there are reasons not to do this.

As an aside to the above aside, I'm building a web framework in another language (Smalltalk) and want developers to be able to develop in a single language (true, 3 languages actually Smalltalk, HTML and CSS) and not learn JS/TS as well. The gorgeous thing about WebComponents is this ability to perfectly wrap them since they are 'self contained'.

[claviska]

This is a good observation. Shoelace was originally created in Stencil, so extending base classes wasn't an option. During the transition to Lit, I never took the time to refactor.

I'm open to moving to the structure you've described. Are you interested in trying this out in a PR?

[ErikOnBike]

I have to consider this. My (wrapped) structure is exactly as I describe, so I don't necessarily need Shoelace in this structure [*]. It does/could however help in future extensions also remaining faithful to the shared behaviour. And helping Shoelace is beneficial if I want to stay a user of it ;-). I'll get back to you in this one.

[*] I have a SlCheckControl which has the checked behaviour, but there is simply no JS/TS counterpart (it is an abstract class). It does not wrap an actual object. The SlCheckbox on the other hand does wrap the JS/TS SlCheckbox and it receives the checked behaviour from its superclass.

[ErikOnBike]

After a little experiment we decided to leave it as is. Since a lot of behaviour is tightly coupled to user interface elements (duh ;-) it might become messy when more and different elements are added and shared behaviour won't help there. The current approach with a single file per element gives a nice single location where all behaviour is to be found.