You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Web components that access the internal form control APIs e.g.:
// Form-associated custom elements must be autonomous custom elements--// meaning they must extend HTMLElement, not one of its subclasses.classMyCounterextendsHTMLElement{// Identify the element as a form-associated custom elementstaticformAssociated=true;constructor(){super();// Get access to the internal form control APIsthis.internals_=this.attachInternals();// internal value for this controlthis.value_=0;}// ...}
have additional lifecycle events: formDisabledCallback, formResetCallback, formAssociatedCallback, formStateRestoreCallback. Adding these to the DOM types would help get type support for their parameters. I suggest the following interface:
π Search Terms
formDisabledCallback, formResetCallback, formAssociatedCallback, formStateRestoreCallback
β Viability Checklist
β Suggestion
Web components that access the internal form control APIs e.g.:
have additional lifecycle events:
formDisabledCallback
,formResetCallback
,formAssociatedCallback
,formStateRestoreCallback
. Adding these to the DOM types would help get type support for their parameters. I suggest the following interface:You can read more about form element internals in https://web.dev/articles/more-capable-form-controls.
π Motivating Example
Providing type safety for custom components.
π» Use Cases
What do you want to use this for?
I am working on a component framework library and would love to have type support for these lifecycle events.
What shortcomings exist with current approaches?
Errors could sneak in because these interfaces aren't documented.
What workarounds are you using in the meantime?
Extending existing DOM apis.
The text was updated successfully, but these errors were encountered: