Better support for custom form controls

[brettwillis]

Currently it's quite hard to make a custom form component in a project using Shoelace (e.g. making a phone input or OTP input that looks like it belongs). Shoelace has it's own utilities for interacting with forms: it swizzles/overrides form component methods, and maintains a form element registry, but these are all "internals" and are not available outside the library.

We are left with two options: either (1) subclass a Shoelace form component (hard if our new component is not structured very similar to an existing component), or (2) rebuild our own components and form behaviours from the ground to be compatible with shoelace components and match the styles (almost fork the whole library).

My proposal is twofold:

1. Expose more of the Shoelace internals (form controllers etc) to make it easy to build our own form components
2. Structure the existing components to better support subclassing
   • Taking SlInput as an example: The HTML is one big template. It would be better for subclassing if roughly each CSS part (part="...") of the template was rendered in an overridable method e.g. renderBase(), renderPrefix(), renderInput() etc.
   • Then if I want to change a particular part, I can just override a particular method
   • The alternative is basically forking the entire Shoelace project to get access to the internals and to just change a few lines of HTML template

[claviska]

The components weren't designed to be subclassed, and we don't officially support that use case for a number of reasons. I suggest composition instead, when possible.

That said, we've recently updated all form controls in Shoelace 3 ("Web Awesome") to use ElementInternals to make them first-class citizens. This allowed us to remove a lot of extra code written just to support form submission.

The ElementInternals API wasn't available when the components were first written, so there's a lot that's changed under the hood and a lot of code that no longer exists :)

I like to think of custom elements as regular HTML elements. Just like you can't subclass HTMLInputElement, you should subclass a Shoelace element. They're designed to do one job and one job well. Trying to [properly] support for subclassing would be a large undertaking leading to more maintenance complexity, more accessibility issues, and take away from our objective of making things as simple as possible to use.

(e.g. making a phone input or OTP input that looks like it belongs)

I've built a passcode form control that we'll be adding to Web Awesome soon. To support things like copy, paste, autocomplete="one-time-code", built-in and custom validation, etc. it requires a separate component that wouldn't have worked well with subclassing.

If you're trying to match aesthetics, I'd suggest leaning on design tokens to achieve consistent styles that will update as you make changes to your theme.

[brettwillis]

Ok I understand. At least using ElementInternals achieves one of those things. Thanks!