Ability to swap out single option

[Snailedlt]

Problem

At the moment it's impossible to swap out a single option in the middle of the options list. This can be troublesome for applications where the order matters.

Example of problem

Take this example:
I have the following options selected:

["Python","TypeScript","C","Dart","Elm"]

Now I want to swap out C with CoffeeScript, and keep the sorting. So I want the options list to change to this:

["Python","TypeScript","CoffeeScript","Dart","Elm"]

In order to do this atm, I would have to delete all options after C, and C itself, then add CoffeeScript and re-add the other options in the correct order. This is not ideal, but not such a big issue in this case. However, the more options there are after the one we want to change, the more tedious and error-prone this approach gets. Imagine having to delete and re-add 40 options, it would be impossible without saving an image of the previous setups somehow.

Solution

To fix this, I suggest that we add input fields to the clicked option on click. So If I click on C, it should replace the C option with an input field. This input field will then be used to search for the replacement for C. If I click out of the dropdown C should still be selected, but if I choose another option in the list, then C should be replaced by that option.

Start state

["Python","TypeScript","C","Dart","Elm"]

Clicking on C

After clicking, the dropdown menu opens up, and C is turned into an input field. In the dropdown list, C is highlighted to clearly show that it was the previously selected option.

Clicking on CoffeeScript

After clicking on CoffeeScript, the input field is replaced with CoffeeScript

End state

["Python","TypeScript","CoffeeScript","Dart","Elm"]

Code used in this example

```html

C

```

alternative styling

 

More Info

Now if we do this, the input field at the end of the multiselect will be obsolete for single-select configurations. Therefore it makes sense to conditionally render it based on this if

if(maxSelect > 1 && options.length > 1) {
    // Render input field after selected options
}

This will also fix #174

Acceptance Criteria

For illustrative purposes I'll be using C as the previously selected option, and CoffeeScript as the option we want to replace it with.

1. Clicking on an option replaces the option (C) with an input field which is automatically focused.
2. When the input field is focused, the normal dropdown list opens up.
3. The previously selected option (C) should be visible at the top of the list, and highlighted.
4. If the user exits the dropdown, the previously selected option (C) should replace the input again. Returning the multiselect to the same state as before.
5. If the user selects a different option (Erlang) from the dropdown. Then the input field should be replaced with said option (Erlang).
6. If only one option is selected, then the input field at the end should not be rendered

[janosh]

Would it solve your use case to allow selected options to be draggable?

[Snailedlt]

@janosh hmm, kinda, but not the linked issue. Drag and drop sounds cool, but I kinda still prefer this suggested solution over it if I were to choose. But maybe both? 😅

[janosh]

@janosh ...but I kinda still prefer this suggested solution over it if I were to choose. But maybe both? 😅

I don't see much added value in turning each selected option into its own on:click input. We can leave this issue open for now to see if anyone wants this enough to make a PR. If that PR doesn't break anything and looks good UI-wise, I'm happy to merge it.

[janosh]

Closing this as not planned since I've heard no further requests/complaints in this area. I think having draggable selected options solves this problem well enough.