Feature Request: el-autocomplete innerHTML for input

[Tonksthebear]

What component (if applicable)
el-autocomplete

Describe the bug
Feature request to allow setting the visible input to the innerHTML of the option that was selected rather than the value

To Reproduce
have with different value and innerHTML and when it's selected, the value of the option is what's visible

Expected behavior
I'd like the option to keep the human friendly innerHTML be the visible selection

Screenshots

Additional context
Add any other context about the problem here.

[Tonksthebear]

I'm currently navigating around this by patching the customElement

  const proto = customElements.get("el-autocomplete").prototype
  const orig = proto.selectOption
  proto.selectOption = function(option) {
    const input = this.getInput()
    const hidden = this.querySelector('input[type="hidden"]')
    orig.call(this, option)
    if (hidden) {
      hidden.value = input.value
      input.value = option.innerText.trim()
    }
  }

[RobinMalfait]

Hey! The issue here is that the el-autocomplete is a wrapper around a normal <input /> to show predefined options. This means that by filtering and picking an option, you essentially fill in the input field.

The value that's present in the input field, is the value that will be submitted when you submit a form.
This is modelled similar to the native datalist where you run into the same kind of issue: https://play.tailwindcss.com/3tWYls51Uw

With @tailwindplus/elements, everything should be available in the DOM so this might be a little bit tricky to get right automatically. I assume that the input[type="hidden"] is something you render yourself in addition to the <el-autocomplete>?

Another issue with this, is that the autocomplete options give you quick access, but you can also type any text that doesn't match a pre-defined option. What do you expect to happen in that case since there is no unique ID (value) to reference?

I think if your workaround works, then you should keep using that.

Will check with the team how we want to go forward with this feature request, given that it diverges from native browser behavior.

[Tonksthebear]

Thanks for the response! I get what you're saying, this feature would require manipulating native browser features.

The way I saw it:
el-autocomplete requires an input element in the markup. In my workaround, el-autocomplete recognizes for input[type="hidden"] and uses that input to store the actual value. The input[type="hidden"] is the input with the correct attributes to attach to the form.
When there is an input[type="hidden"], a second input[form=''] is used for providing the typing input for the user and to display the innerHTML of the selected option to the user. This second input opts out of being a part of the form though, so that only the value of input[type="hidden"] is sent.

For your second question, you are correct. If the user types a new value that does not exist, the workaround would need to add that value to both input[type="hidden"] and the second input. I could see having an option on el-autocomplete for allowing new options or not, but that would definitely increase the scope of its responsibilities

[RobinMalfait]

Hey, I'm moving this one to an internal feature request where instead of this suggestion, we want to introduce a searchable select instead. That way there is a clear distinction between a value and a label.

Going to close this issue for now, but thanks for the suggestion!

[Tonksthebear]

Awesome! Sounds great. One feature request of the searchable select would be an option for whether or not custom options should be allowed. Thanks for considering this ticket!