Description
Operating system
Windows 10 Pro 22H2
Browser Version
Chrome 111.0.5563.147
How severe is the bug?
low
Bug description
The developer documents specifically call-out the case that some addresses, like those in Brooklyn, need to use sublocality_level_1 instead of locality. Since this demo is US-centric, it seems reasonable to account for this case.
Developer Documentation Reference
I'm sure this does not cover every edge case, but it at least covers the one listed in the sample documentation.
Here's a fiddle with the fix and a commit but I believe opening an issue first is the appropriate workflow.
There were also some minor formatting inconsistencies which I don't think are intentional, but I could be wrong.
Finally, geometry is requested and not used which seems counter to the "only pull the fields you need" philosophy in the docs.
All of this is just for your consideration, as I can also understand not wanting to include it given the proviso of needing to adjust for certain situations in the docs. However, I do think this makes the sample more clear.
Steps to reproduce
Open the sample for places-autocomplete-addressform (the link in the bug description goes there)
Start typing address until suggestions appear.
Test address: 134 N Sixth St Brooklyn, NY (Google Store location)
Expected result: City is Brooklyn after selection of autocomplete suggestion showing Brooklyn.
Actual result: City is blank.
Console log output
No response