Open mmun opened 2 years ago
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).
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?
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.
I have a custom element
my-text-input
whose important properties and events mirror that of an<input type="text">
, e.g. It has avalue
property and dispatchesinput
andchange
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.
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.