Why a ComboBox Is Not Enough
You build business applications. You solve the same problems repeatedly.
You build customer searches. You build product autocomplete fields. You build selection popups.
Most UI libraries treat these as separate widgets. They call them lookups or autocomplete boxes. This is a mistake.
These are not different problems. They are the same problem. I call this concept a Locator.
Business applications rely on references.
- A sales order references a customer.
- An invoice references a supplier.
- A transaction references a product.
Databases store these as IDs. Users do not think in IDs. Users think in names, codes, or barcodes.
The real problem is not how you store an ID. The problem is how a user finds the right entity using what they know.
A ComboBox works for small lists. Use it for countries or currencies. These lists have a few dozen rows.
A ComboBox fails for large datasets. You cannot scroll through 100,000 customers. At this scale, you are no longer selecting from a list. You are locating a record.
A Locator is not a UI control. It is a behavior.
A Locator does more than return a value. It resolves a business reference.
When a user selects a product, the app needs more than just a ProductId. It needs the unit price. It needs the VAT rate. It needs the unit of measure.
A Locator provides all of this by resolving the reference within a specific context.
The UI might change:
- On a desktop, it looks like two searchable fields.
- In a grid, it looks like a custom editor.
- On mobile, it looks like a search screen.
The appearance changes, but the behavior stays the same.
A good Locator respects the user. Experienced users use keyboards. A Locator should complete a selection immediately if it finds a unique match. It should only ask for a choice if multiple matches exist.
Stop treating search, autocomplete, and popups as unrelated widgets. Recognize the Locator as a fundamental concept for business software.