Provide a modifier as an alternative to yielding the trigger component

[Techn1x]

Hello! I am looking at implementing this addon in my application for some selections in dropdowns.

I think it would be beneficial to this addon to provide the trigger component as a modifier, that way we can use any element as the trigger, and not require the default div element wrapper around the element that we actually want to be the trigger.

I made a few points for this in the ember-basic-dropdown repo when I asked & implemented the same thing a few years ago https://github.com/cibernox/ember-basic-dropdown/issues/589

TLDR I'd like to see something like this be possible

<SelectBox ... as |sb|>
  <MyInputButton class="some-class" @size="lg" {{sb.TriggerModifier}} >{{sb.value}}</MyInputButton>
  <sb.Options> ... </sb.Options>
</SelectBox>

If this is already do-able somehow, please let me know!

[Techn1x]

It's possible display: contents; could be a way for devs to do this without needing a modifier, though I am unsure the effect that would have on the trigger a11y. And looking at caniuse, its browser support is sketchy on button elements (the trigger component element seems to sometimes be role="button") https://caniuse.com/css-display-contents

<SelectBox ... as |sb|>
  <sb.Trigger style="display: contents;">
    <MyInputButton class="some-class" @size="lg">{{sb.value}}</MyInputButton>
  </sb.Trigger>
  <sb.Options> ... </sb.Options>
</SelectBox>

[amk221]

Thanks... I did consider this, as it would help in our application too. (It would allow us to use our <Button /> component as the trigger, rather than hackily adding class="button" to the Trigger).

I've tested display: contents here: https://github.com/zestia/ember-select-box/commit/876fc20544ee134e6ddd95670ed0a85c4754728d, but that breaks keyboard controls, because the real trigger no longer has focus.

I'm still considering whether to implement a modifier. I think it would be fairly simple, but I want to experiment with it more before committing to it.

[amk221]

Initial experimentation seems like it would have the following problem. Given this example:

<SelectBox as |sb|>
  <input {{sb.input}} />
  <sb.Options>
    <sb.Option>Foo</sb.Option>
  </sb.Options>
</SelectBox>

If you provided some attributes to the input, they would not spread nicely. This is because in the modifier would include code like:

input.setAttribute('tabindex', tabIndexClosedOverBySelectBox)

which would override them, unlike in a component where they can auto merge due to ...attributes

This isn't a deal breaker, its just an observation from initial experimentation