The standard advice on UI selection components in WordPress has become “use a plugin” for anything searchable, and it is costing us dashboard performance and accessibility. I keep opening custom WooCommerce builds where a plain dropdown has to load 500 or more product variations. The DOM chokes, and keyboard users are stuck with it.
On custom blocks and dashboard extensions this is an architectural decision, not a visual one. These components all let someone pick from a list, but they handle volume and visibility in very different ways. If a <select> tag is still your answer to everything, you are frustrating people who will never tell you about it.
Why the right selection component matters
It usually comes down to two things: how many options there are, and whether the user needs to see them without clicking. Hiding a frequently used option behind a click is a reliable way to lose conversions, which I learned the slow way. Past about 7 items, filtering and bulk actions start to matter.
- Dropdown: The list stays hidden until something triggers it. Fine for 5-10 static options.
- Combobox: A text input joined to a dropdown. Necessary once a list runs past 200 items and people need to type to filter.
- Multiselect: Many options at once, usually shown back as “pills” or “chips.”
- Listbox: Everything visible by default, often with a scrollbar. Good when the shape of the data is the point.
- Dual Listbox: The transfer list. What I reach for on jobs like assigning user roles or moving items between categories.
The Combobox is the one people get wrong. Calling it a searchable select undersells what it has to do. The MDN ARIA documentation is clear that a real combobox manages accessibility focus through aria-activedescendant. A library that gets keyboard focus wrong locks out anyone on a screen reader.
Never hide the popular options
One rule I have kept for years: never hide the options people actually use. If your data says 80% of users pick the same three choices, those three do not belong buried in a dropdown. Pre-select them, or show them as buttons or chips and leave the rest behind a heavier interaction. I made the same point when writing about simple accessible UX research: let the data pick the component, not your favorite UI kit.
Refactoring long lists into comboboxes
Inside the Gutenberg editor or a custom React dashboard there is no reason to write one of these yourself. WordPress ships ComboboxControl, which covers most of the work. Here is the refactor I reach for when a standard select starts to feel sluggish.
import { ComboboxControl } from '@wordpress/components';
import { useState } from '@wordpress/element';
const bbioon_UserSelector = ( { users } ) => {
const [ selectedUser, setSelectedUser ] = useState();
// Format users for the control
const options = users.map( ( user ) => ( {
value: user.id,
label: user.display_name,
} ) );
return (
<ComboboxControl
label="Select a User"
value={ selectedUser }
onChange={ ( value ) => setSelectedUser( value ) }
options={ options }
allowReset={ true }
help="Type to search through user accounts"
/>
);
};Compared with a standard select, this keeps the DOM light, since it does not render every option until someone interacts with it. Watch for race conditions if the options come from a remote REST API. Cache the results in a Transient or in local state so you are not hammering the server on every keystroke.
Where the dual listbox wins
The Dual Listbox gets skipped because it eats screen space. For heavier work, assigning roles or bulk editing product attributes, nothing else comes close. The user sees the full selection beside the source list and can check it before committing. That is a lot more accurate than a multiselect dropdown, where the chosen items disappear the moment the menu closes.
If you build one, follow the W3C WAI-ARIA Combobox patterns. Keyboard navigation with the ↑ and ↓ arrow keys is not optional. A list you cannot move through with a keyboard is not ready to ship.
During safe code refactoring I usually find that dropping a heavy JS library for the native @wordpress/components one cuts a good chunk of bundle size and leaves the accessibility in better shape across the site.
If this kind of component work is eating your dev hours, I take it on for clients. I have been wrestling with WordPress since the 4.x days.
Names matter
Getting a team to agree on these words does more than it sounds like it should. Stop calling everything a “dropdown.” A combobox has a text input, a multiselect takes many choices, and a listbox stays visible. Once designers and engineers use the same terms, you spend less time debugging expectations that never matched.
