Consider supporting custom elements

[mmun]

I have a custom element my-text-input whose important properties and events mirror that of an <input type="text">, e.g. It has a value property and dispatches input and change events.

Many of the existing test helpers have checks that prevent them from being used on custom elements because they call these methods in order to provide helpful error messages when an unexpected element occurs.

• ember-test-helpers/addon-test-support/@ember/test-helpers/dom/-is-form-control.ts

  Lines 16 to 25 in d17d27c

  	export default function isFormControl(
  	element: Element | Document | Window
  	): element is FormControl {
  	return (
  	!isWindow(element) &&
  	!isDocument(element) &&
  	FORM_CONTROL_TAGS.indexOf(element.tagName) > -1 &&
  	(element as HTMLInputElement).type !== 'hidden'
  	);
  	}

• ember-test-helpers/addon-test-support/@ember/test-helpers/dom/-is-select-element.ts

  Lines 8 to 12 in d17d27c

  	export default function isSelectElement(
  	element: Element | Document
  	): element is HTMLSelectElement {
  	return !isDocument(element) && element.tagName === 'SELECT';
  	}

I'm wondering if there is a way to weaken these checks so that custom elements can be used. I'm leaning towards allowing custom elements (i.e. elements with a hyphen in the tag name) to bypass the checks. Maybe behind a flag.

You might wonder: is my-text-input built with an <input> under the hood? Can we simply target that directly? In my case, the underlying implementation is indeed a native <input> but it is inside shadow DOM which makes it tedious to access in tests e.g. fillIn(find('my-text-input').shadowRoot.querySelector('input'), 'new text'). More importantly, it should really be treated as an implementation detail that is not leaked to consumers.

The alternative to implementing this suggestion is to have the design system ship its own mirror of the ember test helpers that are coupled to the internals of each custom element and know to delegate to the appropriate underlying inputs.

[rwjblue]

I'm leaning towards allowing custom elements (i.e. elements with a hyphen in the tag name) to bypass the checks.

I think this is fine. Not sure we need a manual opt-in (it doesn't seem breaking change to me, since you couldn't have used custom elements before).

[elidupuis]

I just ran into this issues as well using Shoelace web components. I converted a native select element in our app to sl-select and the isSelectElement method fails because element.tagName === 'SELECT' is no longer true.

In this case, the custom element is not built with a <select> under the hood so it's impossible to use the select() helper provided by ember-test-helpers.

Has there been more thought/discussion around @mmun's proposed options?

[mmun]

The API of Shoelace's select doesn't use selected on the options so I wouldn't expect it to ever work with this helper. It makes sense to have a different set of helpers if the API of your components is fundamentally different than the native ones.