benr77
commented
1 year ago For the moment I have managed to get around this problem by automatically selecting the first <option> if there is no placeholder or existing selected option:
export default class extends Controller {
connect () {
const selects = this.element.querySelectorAll('select');
selects.forEach((select) => {
if (select.querySelector('[value=""]') === null && select.querySelector('[selected]') === null) {
select.querySelector('option:first-child').setAttribute('selected', 'selected');
select.dispatchEvent(new Event('change', { bubbles: true }));
}
})
}
}
carsonbot
smnandre
Using
2.x.devwhich includes #728, and latest Stimulus Bridge3.2.2.This is a bit of a weird one. If I for example use an
EntityTypeor aChoiceTypeto generate a<select>element, and I do not use aplaceholdervalue, we will get HTML such as:When this is rendered by the browser, if no option is selected, and there is no placeholder option, the first option "Option One" will be shown, but without a
selectedattribute.In a normal Symfony form in a standard POST submission, the browser seems to send the "Option One" as though the user had physically selected it. For example, a
NotBlank()validation would PASS.The Problem
If you then move this form into a LiveComponent, the behaviour changes.
Submitting the form without touching the select element does NOT assume that the first element is implicitly selected, and
nullis sent as the select field's value.This means any
NotBlank()validation FAILS, even though as far as the user is concerned, the "Option One" was selected (it was shown as the selected entry in the form field, even though they didn't physically click on it).This then makes a mess when submitting the form, as you get a validation error, and you have to go and click and select the option that is already, as far as you the user is concerned, selected.
I'm guessing this is to do with the way that the Live Component's JS submits the form, and that this is differing in this case with a standard browser form submit.