We need to talk about UI selection components in WordPress. For some reason, the standard advice has become to just “use a plugin” for searchable selects, and it is killing our dashboard performance and accessibility. I have seen too many custom WooCommerce builds where a standard dropdown is forced to load 500+ product variations, creating a massive DOM bottleneck and a nightmare for keyboard users.
When you are building custom blocks or dashboard extensions, the choice isn’t just aesthetic. It is architectural. While all these components support user interaction with lists, they handle data volume and visibility very differently. If you are still slapping a <select> tag on everything, you are probably frustrating your users without even knowing it.
Why Choosing the Right UI Selection Components Matters
The choice often boils down to two factors: the quantity of options and the requirement for immediate visibility. I have learned the hard way that hiding frequently used options behind a click is a quick way to kill conversion rates. Furthermore, if your list exceeds 7 items, you need to start thinking about filtering and bulk actions.
- Dropdown: The list is hidden until triggered. Best for 5-10 static options.
- Combobox: Combines a text input with a dropdown. Essential for large lists (200+ items) where users need to “type to filter.”
- Multiselect: Allows selecting many options, usually displayed as “pills” or “chips.”
- Listbox: All options are visible by default, often with a scrollbar. Helpful when users need to see the “shape” of the data immediately.
- Dual Listbox: The “Transfer List.” This is the gold standard for complex tasks like assigning user roles or moving items between categories.
Specifically, the Combobox is the most misunderstood. It is not just a “searchable select.” According to the MDN ARIA documentation, a true combobox must manage accessibility focus via aria-activedescendant. If your “searchable select” library doesn’t handle keyboard focus correctly, you are effectively locking out users who rely on screen readers.
The Visibility Principle: Never Hide Popular Options
There is one principle I have followed for years: never hide frequently used options. If your data shows that 80% of users select the same three choices, don’t bury them in a dropdown. Therefore, you should either pre-select them or show them as buttons/chips and hide the “rest” behind a more complex interaction. I have written about this before when discussing simple accessible UX research—the data should dictate the component, not your favorite UI kit.
Refactoring Large Lists into Comboboxes
If you are working within the Gutenberg editor or a custom React-based dashboard, you shouldn’t be writing these from scratch. WordPress provides the ComboboxControl which handles most of the heavy lifting. Below is a simple refactor pattern I use 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"
/>
);
};In contrast to a standard select, this component keeps the DOM light because it doesn’t need to render every single option until the user interacts. However, be careful with “Race Conditions” if you are fetching these options via a remote REST API. Always use a Transient or local state to cache results and avoid hammering the server on every keystroke.
The Dual Listbox Advantage
The Dual Listbox is often overlooked because it takes up more screen real estate. But for complex tasks—like assigning roles or bulk-editing product attributes—it is unbeatable. It allows the user to review their full selection list side-by-side with the source list before committing. This is significantly more accurate than a multiselect dropdown where selected items often get hidden once the menu closes.
If you are implementing this, ensure you follow the W3C WAI-ARIA Combobox patterns. Keyboard navigation (↑/↓ arrow keys) is non-negotiable. If you can’t navigate your list with a keyboard, it isn’t ready to ship.
When performing safe code refactoring, I often find that switching from a heavy JS library to the native @wordpress/components library reduces the bundle size significantly while improving the accessibility profile of the entire site.
Look, if this UI selection components stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
Final Takeaway: Names Matter
Aligning your team on these definitions is half the battle. Stop calling everything a “dropdown.” A “Combobox” implies text input; a “Multiselect” implies many choices; a “Listbox” implies persistent visibility. When you speak the same technical language as your designers and engineers, you spend less time debugging wrong expectations and more time shipping code that actually works for everyone.
