feat: add autocomplete/typeahead to place search#542
feat: add autocomplete/typeahead to place search#542ben-haas wants to merge 7 commits intomauriceboe:devfrom
Conversation
field, with Google Places Autocomplete API and Nominatim fallback.
- Add POST /api/maps/autocomplete route and autocompletePlaces service
- Add mapsApi.autocomplete client method
- Add debounced autocomplete dropdown to PlaceFormModal with keyboard
navigation (arrow keys, enter, escape) and mouse selection
- Use place details API to populate form fields on suggestion selection
- Derive location bias from existing trip places for better results
- Extract Google Maps URL regex to shared constant
| website: string | ||
| } | ||
|
|
||
| const GOOGLE_MAPS_URL_RE = /^https?:\/\/(www\.)?(google\.[a-z.]+\/maps|maps\.google\.[a-z.]+|maps\.app\.goo\.gl|goo\.gl)/i |
There was a problem hiding this comment.
This regex is flawed: https://regexr.com/8ljek
|
I forgot to push up the tests. I'll look into the regex as well. |
|
oof.. The failing test has nothing to do with your pr, don't worry. I'll fix it when I have some time. Regarding the regex, it still has some issues. By checking I've updated the test case: https://regexr.com/8ljek An idea you can explore is instead to URL(urlString.trim()), then use the hostname prop from the URL object |
Ya, that seems cleaner. Just pushed an update. |
|
Hey! One question about the location bias logic - currently I understand, it picks the first place with coordinates from the trip: What happens if the trip spans multiple countries (e.g. Japan + China)? The bias will always point to whichever country was added first, which could result in poor suggestions when searching for places in the other country. |
That's a good point! It looks like a bounding box can be used in the locationBias parameter, which would be an improvement, however I'm re-thinking this feature now. There is a lot of nuance to trips that influences how the bias would be useful. For example, if I was planning a road trip, a search bias that included a corridor around my route would be nice, but if I was flying across a country or continent, obviously there is no use in having a search bias along the route. I think the bias parameter should be removed entirely for now and possibly revisited later. There is more complexity than I originally considered and I'm not sure that it adds that much value. What do you think @solarssk? |
…complete accuracy and validation.
…h functionality - Integrate a loading spinner for "Name" input field during place search. - Enhance OpenStreetMap place detail retrieval with Nominatim lookup. - Update `authStore` to track Google Maps API key presence.
|
I caught a bug and made some changes to help with the searchBias. I also merged in dev and resolved all conflicts. Here is a summary: Autocomplete search with location bias
OSM place details fix
Loading UI
Other
|
- Fix race condition: AbortController cancels in-flight autocomplete requests on each keystroke; stale responses no longer overwrite fresh ones - Remove acTrigger state hack; onFocus calls fetchSuggestions directly - Cap autocomplete input at 200 chars server-side (400 on violation) - Filter Nominatim suggestions with empty osm_id segments - Revert getPlaceDetails OSM branch from unconditional parallel fetch to conditional serial: Nominatim called only when Overpass lacks coords/address - Wire places.loadingDetails i18n key to Loader2 spinner via aria-label/role - Add tests: MAPS-017, MAPS-040c, MAPS-093, FE-MAPS-004
|
Closed in favor of #661 |
fix(search-autocomplete): address PR #542 review issues
3 participants
Description
Add real-time autocomplete/typeahead suggestions to the place search field in PlaceFormModal. When users type in the search box, they now see a dropdown of place suggestions powered by Google Places Autocomplete API (with Nominatim fallback for users without a Google API key). Selecting a suggestion fetches full place details and populates the form.
Key changes:
Related Issue or Discussion
Type of Change
Checklist
devdevbranch, notmain