coreui / coreui-pro / 35085699107

94%

push

github

fix: name form fields only when the page asked for one (#1331)

Four components invented a form field name when none was configured, so
a page that never named anything still found generated keys in its
payload, and the names changed between loads because they come from a
counter.

MultiSelect wrote `multi-select<n>` onto the host `<select>`, which turns
a control the page deliberately left out of the payload into a submitted
field. Autocomplete and ChipInput did the same on the text field and on
the hidden input. All three now set a name only when the config or the
markup supplies one, and clear it when the config takes it away. The
multi select remembers the name its markup carried and puts that back on
dispose, so a config name never outlives the component; both it and the
id are re-read where the control is built, before anything consumes
them, so `update({ name })` reaches the select instead of doing nothing.
ChipInput removes its hidden input on dispose, because a teardown and
re-init left two of them submitting one key, the stale one first.

RangeSlider had a different shape of the same problem: with an array
shorter than the number of handles, the template turned the missing entry
into the string `"undefined"` and submitted a field under that name. A
handle the array has no entry for is now left unnamed. A zero is still
written, since a zero is a legal form key.

Docs follow the behaviour on all four pages: three of them said or
implied the field is always submitted, and the chip input snippet had no
name at all, so after this change it would have submitted nothing.

Deliberately not in scope, and recorded: the rest of what the multi
select leaves on the host after dispose (its id, the class, `multiple`,
`required`), and the text field and label `for` the chip input creates.
Both are teardown rather than naming. Rating invents a name the same way,
but a radio group needs a shared one to work at all, so it wants a
decision rather than the same ... (continued)

4048 of 4459 branches covered (90.78%)

Branch coverage included in aggregate %.

21 of 21 new or added lines in 4 files covered. (100.0%)

7398 of 7678 relevant lines covered (96.35%)

726.34 hits per line