coreui / coreui-pro / 34831289884

96%

main: 94%

push

github

refactor(ChipSet, ListBox, Transfer)!: a getter says what it returns (#1284)

* refactor(ChipSet, ListBox, Transfer)!: a getter says what it returns

`getSelected()` returned three different things. ListBox gave the selected
values, ChipSet gave the selected elements while `getSelectedValues()` sat
next to it giving the values, and Transfer required an argument no other
component takes, so the call that works everywhere else crashed on an
undefined property:

  chipSet.getSelected().join(',')  // [object HTMLDivElement],[object …]
  transfer.getSelected()           // TypeError: reading 'listBox'

Every getter now carries the noun it returns: `ListBox.getSelectedValues()`,
`ChipSet.getSelectedElements()`, `Transfer.getSelectedValues(list)`. ChipSet's
`getValues()` and `getSelectedValues()` already said it and are unchanged.

Transfer keeps the `list` argument — `setLoading(loading, list)` takes the
same one — but a missing or unknown list now throws a TypeError naming the two
it accepts instead of failing on `this._sides[undefined]`.

Upstream's `chips` is the reference: `getValues()` and `getSelectedValues()`,
no bare `getSelected()` anywhere in the library.

Docs: the three method tables and the migration guide. React and Vue expose
none of these imperatively, so they are untouched.

* refactor(ChipSet)!: drop the element getter, values are the selection API

A chip carries a value of its own — `data-coreui-chip-value`, falling back to
the chip's trimmed text — and that value is what the rest of the plugin works
with: `unique` and `maxChips` compare values, the add and remove events report
one, `getValues()` and `getSelectedValues()` return them. The list of selected
nodes was a second way to ask the same question with a different answer type,
and upstream's `chips` does not expose it at all.

`getSelectedElements()` becomes the private `_getSelectedChipElements()` next
to `_getChipElements()`, its four callers unchanged. The specs that read it now
... (continued)

5604 of 6247 branches covered (89.71%)

Branch coverage included in aggregate %.

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

10881 of 11284 relevant lines covered (96.43%)

468.41 hits per line