Closed Tropix126 closed 2 years ago
As far as I can see, other libraries went with a selectedId
approach, making what we can put in items
a lot more flexible. Do you think we could have something similar to what Carbon Components does ?
They seem to dynamically create only one input element on selection, which works natively with forms. It looks like it has all the perks and none of the cons to me.
See here : https://carbon-components-svelte.onrender.com/components/ComboBox
So I think i've thought of an approach that i'm happy with. Essentially what will happen is that "value" (the currently selected item) and the "search value" (the contents of the editable
combobox's search input) will be separate.
ComboBox
s. One input will be hidden and be bound to value
while the other will be the one for user input that is bound to searchValue
.value
will select an item if it matches an item
's value
property.searchValue
matches an item's value
property, then a selection will be made and value
will be updated.searchValue
cannot make a selection of the corresponding item is disabled
.value
and searchValue
properties are provided to the ComboBox, then the value
will take priority.implemented as of 537b1cd30b83aa1dd52a9791c27b3a03068812e4 (1.4.1). technically a breaking change, but this is an undocumented component
Currently, our ComboBox component usage looks something like this:
"Selection" occurs when the
name
of the item matches thevalue
passed in (or thevalue
set by the developer). This has some advantages and disadvantages. The main advantage is that matching based on name means that we can bind thevalue
of the input in searchable mode and use the same input for matching selection. This has some drawbacks, though. Items cannot be assigned a separate value from their name. Names must be unique for the ComboBox to behave as expected, and it can overall be a mess using a readable case system. This will need a bit of thinking on my part on how we should handle this. This would techncially be a breaking change under semver, but I consider undocumented components as in the 0.x stage.