Location Input

Location input

Make a location field easy to complete while preserving the person's intended answer. Infer the required precision from the product: “Where are you based?” normally needs a city or country, and current device location may differ from home. Implement only the requested controls; this skill does not authorize deployment or changes to unrelated forms.

Choose data and controls

• Prefer an editable combobox with manual selection. Keep custom text valid unless the product explicitly requires a canonical place. Do not silently expand an abbreviation or replace text on blur.
• Reuse the project's accessible combobox when suitable. Inspect its current documentation and types before introducing another dependency. React Aria supports allowsCustomValue; its async collections can need allowsEmptyCollection and an empty/loading renderer so typing before data arrives still opens suggestions.
• For broad city coverage without per-query costs, consider a lazy-loaded local index from GeoNames cities15000 plus countryInfo and administrative-region names. Measure payload size and search responsiveness; avoid bundling the full dataset into initial application JavaScript. A remote service is appropriate when coverage, localization, or geographic precision justifies it.
• Keep the dataset reproducible and attributed under its actual license. A population-filtered list omits small towns and is not a complete geography database. Retain free text for missing locations.
• Build a small explicit alias layer against stable place IDs: SF → San Francisco, NYC → New York City, Bangalore → Bengaluru, UK → United Kingdom. Do not infer arbitrary acronyms or silently map a metro area to its central city. Add alternate names/local scripts when required by the audience.

Search and selection

Show city, relevant region, and country together to distinguish repeated names. Support country-only answers when the field permits them. Normalize case, accents, and separators for matching while preserving display names. Rank exact names and curated aliases above prefixes, then broader word matches; population can break ties rather than override a stronger match.

Start with about five suggestions, adapted to available mobile space. Preserve Arrow Up/Down, Enter selection, Escape dismissal, Tab navigation, visible focus, and screen-reader labels. Ensure selecting a result does not also advance or submit the form. Allow a no-match answer to remain unchanged.

Represent loading, no matches, and fetch failure separately. A failed dataset fetch must not leave a perpetual “Loading…” message or block ordinary typing. If filtering is already performed externally, check that the component does not filter aliases out again using its own label-only matching.

Store the chosen display label or custom text through the existing form state, draft, validation, and submission path. Add canonical IDs or country codes only when needed by the product; preserve the distinction between selected and unverified free text. Do not expand the schema solely to anticipate future analytics.