Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refine typings for AutocompleteRequest.types to allow for all variations allowed by the API #974

Open
amelekhin opened this issue Apr 20, 2023 · 1 comment
Assignees
Labels
next major: breaking change this is a change that we should wait to bundle into the next major version type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.

Comments

@amelekhin
Copy link

Issue description

In the documentation for the placeAutocomplete method it is said that it supports

Up to five values from Table 1 or Table 2

separated by a vertical bar | as a valid value for the types parameter of the autocomplete endpoint.

However, in places/autocomplete.ts the type of the types property is an enum PlaceAutocompleteType, which supports a very limited set of types/filters for this API, which makes it impossible to use the method with the values from the aforementioned tables without tricking TypeScript with as unknown as PlaceAutocompleteType cast.

This contradicts the documentation of the endpoint, makes it impossible to use singular or combined values from the aforementioned tables and limits the capabilities of the autocompletion.

Suggestion

If these capabilities of filtering by types are not to be deprecated by Google Maps API itself, I would suggest changing the type of types field to string to reach parity in filtering autocompletion predictions between raw API calls and this library.

I would also appreciate if anybody could suggest me another way to, for example, send { types: 'postal_code' }, if there is one in this library and I'm not aware of it. It is supported in raw API calls and I see no reason why it should not be supported in the library.

@amelekhin amelekhin added triage me I really want to be triaged. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns. labels Apr 20, 2023
@wangela
Copy link
Member

wangela commented Apr 20, 2023

If you would like to upvote the priority of this issue, please comment below or react with 👍 so we can see what is popular when we triage.

@amelekhin Thank you for opening this issue. 🙏
Please check out these other resources that might help you get to a resolution in the meantime:

This is an automated message, feel free to ignore.

@usefulthink usefulthink changed the title postal_code is not a valid types value for client.placeAutocomplete() Refine typings for AutocompleteRequest.types to allow for all variations allowed by the API (postal_code is not a valid types value for client.placeAutocomplete()) Oct 10, 2023
@usefulthink usefulthink changed the title Refine typings for AutocompleteRequest.types to allow for all variations allowed by the API (postal_code is not a valid types value for client.placeAutocomplete()) Refine typings for AutocompleteRequest.types to allow for all variations allowed by the API Oct 10, 2023
@usefulthink usefulthink added next major: breaking change this is a change that we should wait to bundle into the next major version and removed triage me I really want to be triaged. labels Oct 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
next major: breaking change this is a change that we should wait to bundle into the next major version type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Projects
None yet
Development

No branches or pull requests

3 participants