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.

That was the durable lesson from this work.

We 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 we wire the chosen place back into our form.

But the thing we learned was that a place picker is not just a data problem. It is also an interaction-design problem.

What we observed

The key observation was on mobile-sized screens.

As soon as the user typed into the address field, the experience stopped feeling like “our form with a dropdown” and started feeling like “Google’s search UI inside our page.”

Observed behavior:

• the address field effectively took over the visible screen
• the rest of the page felt hidden behind a Google-owned overlay-like flow
• we saw the same behavior on a real iPhone and in Chrome mobile emulation on desktop

This is what the default widget felt like on mobile.

That last point matters. The direct observation was “this reproduces outside Safari too.” My inference from that observation was that we were fighting the way the widget wanted the field to behave, not just a browser quirk.

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

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

That was not the reason we 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

We 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.

It still was not the right component for our app.

The mismatch was not “this example is bad.” The mismatch was “this example is solving a slightly different product problem.”

Three concrete 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 our 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 we 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 we actually needed

Once we 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 ourselves.

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"] })

This is the same task after we kept the UI and only used Google for place data.

That let us 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 us remove the bad parts:

• mobile takeover behavior
• Google-owned layout decisions inside our form
• UI states we could not shape cleanly

One small but important follow-on lesson came after that. Once we owned the control, we also realized success did not need its own extra UI. The resolved address in the field was enough. Helper text below the input worked better when it was reserved 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 our case, we chose a small Google Maps footer inside the suggestion panel. That is one compliant layout, not the only possible one, but the broader lesson is simple: 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 question.

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.