Provide an element that converts large radio/checkbox option to select list

As it targeted for D10 I think it could use typed data to detect length instead of render array guessing, so added as related #3249600: Add support for PHP 8.1 Enums as allowed values for list_* field types

Hello,

Created a MR for this task that provides a new Form element called "dynamic_options" that depending on the number of items behaves as a set of checkboxes/radiobuttons or a select element.

The number of options to determine one behavior or the other can be determined by the #select_threshold property.

Attaching an example of the behavior of this form element and the source code necessary to generate that form.

This MR will require tests, but here I'm presenting a first candidate to move on one direction or the other depending on the feedback given.

Thank you!

Thanks all! I think this can be a great UX improvement for Drupal.

From the current work I'd miss a way to test it: would you mind adding a Widget too? I would love to test this via the UI and be able to see it "in action" so we can convince everybody that this is needed. Also, if you could add some suggestion for testing steps once it is done it'd be great to get people's +1.

Hi @ckrina

Added the widget as you suggested to allow site admins to use this new form element from the Drupal UI.

Issue description has been updated with some instructions and screenshots. Please let me know if you think that anything else can be added.

Thank you!

We've discussed this during the weekly UX meeting #3318005: Drupal Usability Meeting 2022-11-04 and everybody agreed on this being ok with this improvement.

On the other side, they suggested to change the following copy from the UI:

• Dynamic options > Checkbox/radios or select
• Select threshold > Switch to Select at
• Number of available options after which the select is used. > Use checkboxes or radio buttons up to this many options.

And also to add a suffix to the advanced form where you can choose the amount of items as "options".

So removing the "Needs usability review" tag.

Thank you very much for the quick feedback.

Form changes have been already addressed.

We discussed this issue at #3318005: Drupal Usability Meeting 2022-11-04. (See Comment #10.) That issue will have a link to a recording of the meeting.

For the record, the attendees at the usability meeting were @AaronMcHale, @anmolgoyal74, @benjifisher, @ckrina, @kae76, @rkoller, @shaal, @simohell, and @worldlinemine.

During the usability meeting, we agreed that adding a new form widget, as in the current patch, is the right thing to do. Thinking about it some more, I am not so sure.

The new widget has the setting "Switch to Select at". If we set that to 0 (or -1 or whatever is interpreted as "never") then we could replace the existing checkboxes/radio widget with the new one and it would not be disruptive. We would have to decide what the default behavior will be for newly added fields.

The advantage of this approach is that we do not add an extra option to the list of available widgets. We do not have to worry about putting "select" at the end of the widget name or at the beginning. (There are arguments for both, and we discussed it at the usability meeting.) Less is more! Here is a screenshot using the current feature branch for this issue:

Looking at that makes me wonder:

• Why aren't the options in alphabetical order?
• Do we really need separate widgets for Autocomplete and Autocomplete (Tags style)? Can we make that one option with a setting?

I am not suggesting that we do anything about those two questions on this issue, but if anyone wants to look for existing issues and create new ones if needed, I will be grateful.

In fact, why not replace both the existing Checkboxes/radio widget and the Select widget with the new, configurable one? Use a setting of -1 to mean never use Select and a setting of 0 to mean always use Select.

I am setting the status to NW for a response. The response could be that you do not like my ideas, or it could be an updated MR to implement them.

The new widget has the setting "Switch to Select at". If we set that to 0 (or -1 or whatever is interpreted as "never") then we could replace the existing checkboxes/radio widget with the new one and it would not be disruptive. We would have to decide what the default behavior will be for newly added fields.

I really like the idea of improving something that we already have instead of creating something new! I wouldn't go as far as merging the Checkboxes/radio widget with the Select one though.

So as @benjifisher said, I would try to improve the UX of the existing Checkboxes/radio by adding the option to switch automatically to a Select. I'd also hide it behind the advanced options/widget settings, and a checkbox disabled by default that would activate the feature with the 7 as the default number (and an input field to change it).

Any thoughts on the implementation perspective and its repercussions?

Any thoughts on the implementation perspective and its repercussions?

I agree that updating the existing widget instead of adding a new one is a good idea, but I believe there are some secondary effects we should pay attention to before making the decision.

Adding new settings to existing widget

Setting these properties by default to behave like the existing widget would not be a big deal, and probably it would not require too much code. To be more solid, we might need to add an update hook to update all the existing instances of the widget. Then export the results and update the corresponding form display yml files affected.
It would imply to set by default settings to behave like checkboxes/radio buttons current widget by default and explicitly set the dynamic behavior afterwards where considered necessary.

Breaking existing contrib & custom modules that extend the current widget

Given that besides of the new extra widget settings, it would make use of this new dynamic_options form element, widgets created existing the current widget class could be affected.
Not sure if this could be even considered as a Breaking BC change.
To alleviate this, we could add this new widget, and modify the existing one to extend it. Then deprecate the existing one and get rid of it in next major release.

I think those are my main concerns from the technical point of view regarding this topic. Any feedback from someone with a better knowledge of the release cycle would be much appreciated to validate the situations explained above.

Thanks!

I think as long as when we change the existing widget we make the new behaviour not how existing configurations of the widget work we'd be okay. As plugin implementation we don't support the BC policy on \Drupal\Core\Field\Plugin\Field\FieldWidget\OptionsButtonsWidget...

But that's actually also interesting - the class name is not great if we make it capable of being a select so maybe we'll need to rename the class here too - which would mean deprecating the current class name. And then there's the question of the plugin ID... it's options_buttons which also is not great.

So perhaps the best thing to do is:

• Add a new widget with the correct class name and plugin ID
• Deprecate \Drupal\Core\Field\Plugin\Field\FieldWidget\OptionsButtonsWidget
• Deprecate \Drupal\Core\Field\Plugin\Field\FieldWidget\OptionsSelectWidget
• Allow the automatic transition to be disabled and the user can choose between select list or radio/checkbox.
• migrate existing configurations in the new widget - but with automatic transition disable and the choice between select list or radio/checkbox assigned corrrectly

Thank you for your feedback here @alexpott

Let me try to add some questions to your your suggested steps, to confirm that we are in the same page:

• Do you have any suggestion about a valid name for the plugin/class? Could be just
  options/\Drupal\Core\Field\Plugin\Field\FieldWidget\OptionsWidget
• OK, we can deprecate it
• OK, we can deprecate it
• We can add that extra feature to the new widget, not a big deal
• Do you mean a post_update hook that moves all existing options_buttons & options_select instances to the new widget?

Thanks!

Hello,

I have been working on the proposal to provide a widget that allows to force the element or allow the dynamic conversion depending on the number of options.

This is the current status of the widget settings form:

Feedback is welcome!

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.