When Google Should Supply the Place Data, but Not the UI

Google’s Places tools are good at finding places. That does not mean Google’s default autocomplete UI is a good fit for your product.

I started with Google’s newer widget, google.maps.places.PlaceAutocompleteElement. The appeal was obvious: Google handles the suggestion UI and a lot of the interaction complexity, and I wire the chosen place back into the form. But a place picker involves interaction design too, and dropping in the widget hands that decision to Google.

What I observed

The trouble showed up on mobile-sized screens. As soon as someone typed into the address field, the experience stopped feeling like “my form with a dropdown” and started feeling like “Google’s search UI inside my page.” The field effectively took over the visible screen, and the rest of the page felt hidden behind a Google-owned, overlay-like flow. I saw the same thing on a real iPhone and in Chrome’s mobile emulation on desktop.

Here it is:

It also reproduced outside Safari. I took that to mean I was fighting the way the widget wanted the field to behave, not just a browser quirk.

I also hit a separate failure mode: a bad browser-key configuration produced Google-owned request errors like this one:

POST https://places.googleapis.com/$rpc/google.maps.places.v1.Places/AutocompletePlaces 403 (Forbidden)

That wasn’t why I replaced the widget. It was a separate reminder that when Google owns the control, you inherit Google’s failure surface too.

Why a nice public example still was not a drop-in

I found a public Shadcn-style example that used the modern Places API correctly. It queried suggestions with AutocompleteSuggestion.fetchAutocompleteSuggestions(...), used AutocompleteSessionToken, and resolved the final place with:

await place.fetchFields({ fields: ['formattedAddress', 'location'] })

That was the right technical direction, but still not the right component for my app. The example wasn’t bad; it was solving a slightly different product problem. Three differences mattered:

• it loaded Google Maps its own way instead of reusing the app’s existing setup
• it rendered suggestions outside the form instead of directly under the field, while my preferences page already had a good local dropdown pattern
• it had its own rules for positioning and closing the menu instead of matching the behavior I already used elsewhere

That was the turning point for me. A technically correct example can still be the wrong UX fit for your product.

What I actually needed

Once I stopped trying to style around the widget, the solution got simpler: keep Google for place suggestions and place details, but own the input and dropdown myself. In practice, that meant an app-controlled text input, an inline suggestions panel, and Google only for the data layer:

AutocompleteSuggestion.fetchAutocompleteSuggestions(...)
prediction.toPlace()
await place.fetchFields({ fields: ["formattedAddress", "location"] })

Here’s the same flow with my own input and dropdown, Google supplying only the place data.

That let me keep the nice parts:

• place-name search, not just literal street addresses
• exact coordinates when a user picks a result
• fallback to manual entry when autocomplete is unavailable

And it let me remove the bad parts:

• mobile takeover behavior
• Google-owned layout decisions inside my form
• UI states I couldn’t shape cleanly

Owning the control taught me one more thing: success didn’t need its own extra UI. The resolved address sitting in the field was enough, and the helper text below the input worked better once I reserved it for exceptions.

The constraint you still have to respect

Owning the UI does not mean you can ignore Google’s rules. If you render custom autocomplete predictions without an embedded Google map, Google’s policies require attribution. In my case, I chose a small Google Maps footer inside the suggestion panel. That is one compliant layout, not the only possible one. If you replace Google’s UI, plan for attribution up front.

Takeaway

If you care about polish, separate these two questions early:

1. Who should provide the place data?
2. Who should own the interaction model?

Google is very good at the first one. If the field lives inside a dense product workflow and you want the experience to feel native, you probably want to own the second one yourself.

That is more work than dropping in the widget. But it is how you avoid spending days trying to “fix” a UI that was never really yours.