[Dropdown] Allow to edit "multiple item"

[mvorisek]

Feature Request

repro: https://jsfiddle.net/evor619s/

Dropdown multiple should allow to fix typos/change in/of already added item.

Steps to reproduce:

1. open the repro
2. click the "foo" item
3. I would expect the item to be changed to regular input (like when searching/adding a new item) and be able to change it to "f2oo" with "mouse click after letter "f" and typing 2 on the keyboard"

Depending on the allowAdditions config the item can or can't be edited to unlisted value.

This feature request is especially useful for longer items like email addresses. (currently the existing item has to be deleted and retyped)

[BrianJavier99]

Hello @mvorisek, I have attempted to implement this feature request in this pull request.

My implementation is a little bit different: it allows you to edit existing selected items, instead of using the search input to edit the values, as I have found it to be possibly confusing in a few situations.

[mvorisek]

Might I know what exactly you found confusing?

I belive the editing should be done using the regular editing input/API to maintain the same look&feel. User should be definitely allowed to change some value to a value listed from all existing values (or remote API).

[lubber-de]

What about using contenteditable="plaintext-only" instead of switching to an input field? This way the whole label stays visible as it is?

[BrianJavier99]

Might I know what exactly you found confusing?

I belive the editing should be done using the regular editing input/API to maintain the same look&feel. User should be definitely allowed to change some value to a value listed from all existing values (or remote API).

• When trying to edit an existing item while there's an existing value in the search input, do we discard the current value in the search input and replace it with the value of what we're trying to edit?
  

• What happens if we try to edit another input while we're in the middle editing one? This can lead to multiple selected items being accidentally deleted.
  
  

[BrianJavier99]

What about using contenteditable="plaintext-only" instead of switching to an input field? This way the whole label stays visible as it is?

@lubber-de I've tried doing that, but it seems like the close button is also "editable" despite the plaintext-only setting, not to mention the line endings also messing up the alignment of the elements inside the label

EDIT: Sorry, it seems that the plaintext-only works as intended avoiding the deletion of the iconPlaintext-only exhibits wonky behavior. Sometimes it prevents deletion of the icon, sometimes it doesn't. We also end up with this:

Maybe I can try to hide the close icon when editing and just bring it back afterwards.
Styling also gets messed up if we delete the text all the way.
Before:

After:

Here's the fiddle I used to experiment:
https://jsfiddle.net/ReiVanBjair/djftxr4w/10/

Should we still proceed with this and find a way to make it work?

[mvorisek]

When trying to edit an existing item while there's an existing value in the search input, do we discard the current value in the search input and replace it with the value of what we're trying to edit?

There are many challenges and typical usecases.

Usecase of this issue: edit existing multiple selection.

Then there is another unsupported usecase yet: edit order.

Initially, I have written "I would expect the item to be changed to regular input" like currently implemented in #3247. I am not sure how feasible this really is, maybe we should relax the requirement of "editing the existing item in place" and implement this like:

When a "selected value" (any selected value of dropdown multiple) is clicked, remove it from the values and replace the existing "search value" with the clicked one.

Such value can be added using regular lifecycle as any new value. When order matters, user should be able to reorder the values.

Then we can debug UX, ie. if original "search value" should preserved or possibly display some dropdown warning like "Clear current search input first to edit an existing item". Maybe simply replacing the unsaved search input is enough.

[BrianJavier99]

When a "selected value" (any selected value of dropdown multiple) is clicked, remove it from the values and replace the existing "search value" with the clicked one.

Okay, we can work on that. Say on the image above, I click email2@domain.com.

Now email2@domain.com is in the search input, and the text "value to be discarded" is gone.

Maybe simply replacing the unsaved search input is enough.

Say user accidentally clicks another selected value (in this case email@domain.com), email2@domain.com, which is now the "unsaved search input", will also get discarded. With the situation above, you're now left with no selected values in the dropdown:

This means clicks become risky for the user and can possibly cause them twice the workload due to having to retype the accidentally removed selected value (that is, if they can even remember what was unintentionally deleted in the first place).

Then we can debug UX, ie. if original "search value" should preserved

This would mean:

1. Current search input is stored somewhere, it is then replaced by the value of whatever selected item we are editing.
2. We "save" the item we are editing by pressing enter
3. The preserved value appears again.

Now the question would be if this is an acceptable approach, and also how "deep" do we wanna go. Do we only save once, twice, as many as there are editable selected values?

Personally, I think implementing this is a major UX hassle, which is why I opted to just be able to directly edit each selected value. That way they each have their own input, and you can't mix one from the other.

If I could also ask, is there any particular reason why it isn't feasible adding a text input inside the labels?

[mvorisek]

Say user accidentally clicks another selected value...

You are right, my UX teacher always told us "any action should be possible to be reverted/undone".

So yes, the edit should be possible to cancel somehow. Or to not allow the edit if seach input is not empty.

If I could also ask, is there any particular reason why it isn't feasible adding a text input inside the labels?

I am not againts. However, I require any editing to allow regular search.

[BrianJavier99]

I am not againts. However, I require any editing to allow regular search.

Okay, I now understand. This indeed makes the current implementation of inline editing of the item label an imperfect solution at best. I'm thinking if it's good to make the dropdown menu respond to the value being edited? Although that can possibly increase user confusion if the dropdown menu responds to the inline edit while there's an existing value.

We have the following options:

Dropdown menu will prioritize the item being edited

• Search input text can be greyed out / set as inactive

Merge the values of the search and edit input

• Now this is something that I'm not so sure if we should do. This is just plain confusing.

Have a separate dropdown menu for edit and search input

• Different query for the edit and search
• Precise and possibly the best of both worlds
• ❗Can be cluttered unless we carefully design it.

Utilize the search input when editing

• We will need to prevent editing when there is an existing value in the search input to avoid accidental removal of selected items.

Perhaps our maintainers can help provide insight in this, maybe can I ask you @lubber-de? Others can also put suggestions or tag someone else that might provide insight.