Should x-model with select have the ability to decide if it should use .text or .value

[byjpr]

I'm wondering if I should write a PR to create a modifier that would allow the selection of either the value of the selected option or text.

Currently, the code will check for value, and if no value, it will take the text.

alpine/packages/alpinejs/src/directives/x-model.js

Lines 102 to 104 in 5cb4046

	: Array.from(event.target.selectedOptions).map(option => {
	return option.value || option.text
	})

Current behaviour

If you have the following code:

<select name="user[role]" x-model="select">
  <option value="role1" selected="">Admin</option>
  <option value="role2">User</option>
</select>

The text inside <span x-text="select"></span> would be role1.

However,

<select name="user[role]" x-model="select">
  <option selected="">Admin</option>
  <option>User</option>
</select>

The text inside <span x-text="select"></span> would be Admin.

What would be introduced?

Another modifier that would set preference for text. E.G: x-model.text="select"

[SimoTod]

I think the code you attached is only relevant for multi-select.
In general, it's not an Alpine thing, the value of a standard select box is always the text if a value attribute is not provided: https://codepen.io/SimoTod/pen/zYpzwgP

[ekwoka]

Yes, because you're actively accessing both form the OPTION element.

The behavior of the SELECT element is that its value will be the values if present otherwise the text.

The select element itself will not provide you the value and text content of the options.

That's the native behavior that Alpine replicates.

[asbjornu]

Ok, that makes sense. But don't you agree that it's a valid request to have Alpine expose both, somehow? Having to dive down into plain JS to dig out data from the DOM is very clunky compared to just using Alpine's fabulous built-in x-model and x-bind attributes.

[SimoTod]

@asbjornu you can do exactly the same. It's not any clunkier than the original example

<form x-data="{value: null, text: null}">
    <select id="numbers" x-model="value" @change="text = $event.target.selectedOptions[0].text">
        <option value="1">One</option>
        <option value="2">Two</option>
        <option value="3">Three</option>
    </select>
    <p>Value: <span x-text="value"><span></p>
    <p>Text: <span x-text="text"><span></p>
</form>

[asbjornu]

@SimoTod, I did not know about $event and did not think about using both x-model and @change simultaneously. 👍🏼 A bit clunky still, but only compared to how clean most Alpine code is. Thanks! 🙏🏼

[ekwoka]

It can be reasonable to want both.

I think the focus of the library (as any should) is staying fairly "spec compliant" where behaviors are defined.

That's the primary.

Then other behaviors would need to evaluate if there is a need for something more, how common that need is, and how painful it is to implement in user land.