List key|label entry field is textarea, which doesn't give guidance towards the expected input

This will most likely require an API change if done properly. Otherwise a transformation between an array and textarea has to be made like in the Options Elements module which I linked now to the issue description.

IIRC @quicksketch had a contrib module which provided a UI pattern for those kind of needs.

The proposal makes key|label entry much understandable than it is currently. Maybe we can even make it more clear by not mentioning 'key' at all, but just naming it 'value'. That said, I miss the 'Remove value' options per row in the image.

The descriptions says we add certain markup (is this still so?), I would say we shouldn't advertise it when the 'simple' widget is used.
So maybe we can also have an advanced widget (the current one) as well. Because bulk entry also seems tiresome with the 'simple' widget.
If we support both we would need a toggle for the two input modes.

With select2 you can have a free text tag that transforms to a dismissable pill. Yet another reason to get that library into core.

@tkoleary that lib is similar to Chosen right?

Right, but a bit more robust and well adopted

Implemented a prototype based on the proposed solution in the issue summary. The code definitely still needs clean-up, and it completely fails into taking into account other list field types.

There's probably still some minor modifications we should make to the UX. We should at least consider implementing a delete button for a row. This would improve the UX as without the delete button it's quite tedious to remove an option. We also could potentially disable the delete button when there's existing data since in this case options cannot be removed anymore.

Tweaked just enough to get tests to run, and then looked into the failures. Lots of "settings[allowed_values]" not found.

Also this could use #parents on the label/key fields to strip out all the table/item noise of those keys, but not doing that until we're more certain about the direction.

Working on this

The same usability problem exists for:

1. \Drupal\ckeditor5\Plugin\CKEditor5Plugin\Style
2. and soon also \Drupal\ckeditor5\Plugin\CKEditor5Plugin\CodeBlock

— see #3282233-34: Ability to configure additional languages (e.g. "bash" or "SQL") for CKEditor 5 CodeBlock plugin.

P.S.: see \Drupal\ckeditor5\Plugin\CKEditor4To5Upgrade\Core::mapCKEditor4SettingsToCKEditor5Configuration() and \Drupal\ckeditor5\Plugin\CKEditor5Plugin\Style::parseStylesFormValue() for how we dealt with the transition from storing the configuration in this exact way to something more structured 🤓

I was not able to work on this more since my last commit.

Thanks for the pointers @Wim Leers!

Seems to be several open threads on the MR

The screenshots in the issue summary appear to be outdated.

Did find it odd that when I added a field that it made 6 value fields by default. Shouldn't it just be 1 and allow users to add more as needed?

Also should the help text be moved to the top?

Referring to this

The name will be used in displayed options and edit forms.
The value is automatically generated machine name of the name provided and will be the stored value.

Wasn't super clear where or how the value is set, or that I could edit the machine name if I wanted to update the value of the option.

Updated issue summary with current screenshots

i think this needs a "little review" ... at least to be checked what's left to be done ... if not "ready".

My points from #38 appear to have been addressed

Retested on 11.x
Added a list to the Article content type
Verified I see 1 field by default
Added a label and edited the machine name to something completely different
Added a second value
Created an Article
Inspecting the dropdown the labels and values match exactly what I did.

Also applied the patch back n forth and the list field updated without issue.

Discussed with @ckrina and she liked the improvement. However, she mentioned that it would be nice if we could display the float and integer fields side by side. Let's research if something that we could do easily because it seems like it would be a nice way to take this a step further 👍

Addressed #43 feedback.

Confirmed the change in #43. Excited to see this land!

Retested with List(text), Floats, ints and no new issues to report.

This is looking good! I opened a few threads in the MR that should be addressed but it's probably all pretty simple stuff.

Points appear to have been addressed.

This MR was not very accommodating to a rebase so here's the 11x as a patch.

Was about to commit based on review/rtbc then noticed #43 which mentions

Discussed with @ckrina and she liked the improvement. However, she mentioned that it would be nice if we could display the float and integer fields side by side. Let's research if something that we could do easily because it seems like it would be a nice way to take this a step further 👍

I'd like to at least clarify what that is asking for and see if it was in fact considered. I believe @lauriii will be around Monday to clear this up. Setting to postponed as it's possible this might not need additional work. If we decide to not pursue that change this can go back to RTBC.

Looking at the commit history I now see what was meant by the statement I wondered about in #55, and it has been completed satisfactorily.

I made some minor tweaks (its all in the history, and now this is committed to 11.x (which means it'll first appear in 10.2.

Really great improvements here, and its just ambitious enough that it is good for this to be at the beginning of a new release cycle.

I meant to leave a comment.

This issue introduce a deprecation in \Drupal\options\Plugin\Field\FieldType\ListItemBase::extractAllowedValues and thus needs a change record. This is blocking #3048495: Fix Drupal.Semantics.FunctionTriggerError coding standard.

Created a CR: https://www.drupal.org/node/3376368

@lauriii, Thank you!

The changes to ListStringItem to use machine name break when there is existing data on a site that doesn't match the machine name format. Opened #3411419: Regression from #2521800: using machine name element for ListStringItem breaks with existing data to revert just that bit.

For anyone arriving here, I've opened #3440019: ListStringItem is difficult to work with when you have a long pre-defined list