coreui / coreui-pro / 35087607624

94%

push

github

fix(OTPInput): leave the slots out of the form, keep only the hidden input named (#1333)

Every visible slot was given `name="<name>-<index>"` on top of the hidden
input that carries the value, so a form sent one key per slot plus the
real one: three slots and `name="code"` submitted `code-0`, `code-1`,
`code-2` and `code`. The option is documented as the name of the hidden
input, and that is now what it is. A `name` or an `id` the page wrote on
a slot in its own markup was overwritten by the generated one; both are
left alone.

Making the hidden input the only named element exposed where it went out
of step with what the field shows, which the named slots used to mask. It
was seeded from `value` alone, so slots rendered with their own `value`
attributes submitted an empty string while reading `12` on screen, and so
did a field whose slots a browser restored on reload. `reset()` repainted
the slots and then blanked it. It is now built from the slots and re-read
whenever they are repainted, so what the form sends is what the field
shows, and `value: 0` reaches the slots too, where `|| ''` used to drop
it.

Reading the slots runs them through the same mask as typing and pasting.
Without that, a `value` written into the markup reached the submitted key
unchecked: with `type: "number"` a slot holding `abc` used to go to
`code-0`, which a server ignored, and would now have gone to `code`.

`dispose()` removes the hidden input it created, so a teardown and
re-init no longer leaves two of them submitting the same name.

One consequence worth knowing: `reset()` restores the configured value,
and if that fills every slot the component now reports `complete`, which
it could not do while the hidden value was blanked.

The test that pinned `otp-code-0` was asserting the defect; it now pins
the absence, alongside the submitted payload, a slot name and id written
by the page, a zero value, a character the mask rejects, and a dispose
cycle. Six are red on main.

Thr... (continued)

4048 of 4459 branches covered (90.78%)

Branch coverage included in aggregate %.

9 of 9 new or added lines in 1 file covered. (100.0%)

7399 of 7679 relevant lines covered (96.35%)

726.99 hits per line