Option to not unselect current selection on click

[mhkeller]

If an item is selected in my list and I click on it, it gets unselected. Is there a prop to disable this behavior so that it behaves more like a native <select> element and the list always has a selection? I thought required would do that but I get the same behavior.

[mskocik]

It seems this behavior has disappeared in transition from v3. It makes sense to be coupled with required property.

[scoopandrun]

This behavior (as it is now after the modifications) is strange.
In v3, you could have a required select and still remove the current value to have an empty input. I think this is the expected behavior. Furthermore, clicking a filled input (or the selected value in the input or in the list) didn't remove the selected value.

The required attribute shouldn't prevent you from clearing an input, as it doesn't with native HTML elements.
The required attribute means that, when form validation is performed (usually when the form is submitted), the validation should fail if the input is empty (with an explanation message, ideally). It doesn't mean that you are stuck with the value you have entered.
As Svelecte is intended to replace native <select> elements (hence it is intended to act as a form input), the required attribute should respect the HTML meaning. In the Svelecte docs page for the properties, the required line clearly states:

you work with it as standard <select> element

I find the new behavior counter-intuitive.
To change the current value, you have to select another value (OK, I can work with that). But on creatable inputs, you have to type a new value after the current one to clear the current one (so the user has to guess that they must "overwrite" the current value by typing a new one).

In the example above, I cannot erase "Current" with Backspace or Delete, it doesn't do anything and there is no feedback to the user. I have to write "New" after "Current" to erase "Current".
To the user, it seems like they are writing a second value into the input, not overwriting the current one.
I think this is a breaking change (UX-wise), as it changes the way the input worked until now and the new behavior is unlike any other form inputs (where you can clear the input even if it's required).

I just updated to v4 and discovered this a little bit late in the process, by accident, as it is not mentioned in the docs.

If the issue is with a value being deselected upon clicking on it, the solution shouldn't involve the required attribute.

[mskocik]

You are mixing 2 things:

1. single select creatable & required
2. single select behavior in general

ad 1. this is definitely a bug. You should be able to always remove created option

ad 2. I would keep it the it is. You can force the same behavior with native select, that after initial selection, there will always be one. And if you want to force selection, it makes sense to couple it with required property.

Maybe the ability to "de-select" option (for non-required select) by selecting it again should / could be controllable by som property 🤔 Because that's not how native single-select behaves.

[scoopandrun]

Indeed, I was sure that you could de-select a native <select> 🤔

I didn't know that you could include a "hidden" option with display: none. Nice.

But I agree with the fact that a creatable option should be removed. If the field is required, then it should become "invalid" (as it was before version 4.4.0).

[mskocik]

I created separated issue for the creatable one.

Regarding the ability to deselect option by clicking on it again: I changed the behavior in v4 to be the same for single & multi select (for multiselect you need to enable keepSelectionInList to have the ability to select it again)

But you would prefer the v3 behavior? To be unable to de-select option by selecting it again, right? It will just add another difference between single & multiselect.

I didn't know that you could include a "hidden" option with display: none. Nice.

Btw at least iPhone is still showing even the placeholder item, but work as expected on desktop.

[scoopandrun]

But you would prefer the v3 behavior?

I don't think that what I prefer is relevant. The component isn't made for me only.

To be unable to de-select option by selecting it again, right? It will just add another difference between single & multiselect.

I don't see this behavior with V3. When an item is selected, I can click again on the component (the dropdown list then shows up), I can click on the same item in the dropdown list (if it's a single select) and none of these clicks de-selects the option.
I also tried with multiple and I don't experience this neither. I can de-select options by clicking on the cross next to the selected option, but that's the expected behavior.

I don't really see what @mhkeller means in the original post. I just know that since v4.4.0 you can't clear a required input once you have selected an option.

[mskocik]

I've just released new version (4.5.0) with new property deselectMode, where de-selection behavior can be specified. It defaults to current behavior (ie. 'toggling' between selected/deselected). This behavior is consistent with multiselect.

@scoopandrun you want to set this property to native value. It has v3-like/native behavior.

@mhkeller you want to set this property to none. After select, selection cannot be cleared only changed.

This prop is available in global config, so you can specify it for whole app.