[Feat] Support the new Google Places Library (Autocomplete Service)

[Tigatok]

Target Use Case

I would like to be able to use some of the new places functionality, such as filtering out more places (golf_course) which is available in the new places api, but not in legacy.

Edit: Clarifying that I'm looking for the new Autocomplete Service functionality within the places library.

Proposal

We should support the new version of the places service.

[usefulthink]

As far as the new APIs are already supported in the Maps JavaScript API, they are supported in this library as well. For example to use the new Place class and it's text-search:

const SomeComponent = () => {
  const placesLib = useMapsLibrary("places");
  const [placeResults, setPlaceResults] = useState();

  useEffect(() => {
    if (!placesLib) return;

    const request = {
      textQuery: "Tacos in Mountain View",
      fields: ["displayName", "location", "businessStatus"],
      includedType: "restaurant",
      locationBias: { lat: 37.4161493, lng: -122.0812166 },
      isOpenNow: true,
      language: "en-US",
      maxResultCount: 8,
      minRating: 3.2,
      region: "us",
      useStrictTypeFiltering: false,
    };

    Place.searchByText(request).then(({ places }) => {
      setPlaceResults(places);
    });
  }, [places]);
};

What was the kind of support you are looking for?

[Tigatok]

@usefulthink Hmm I had an error thrown the other day when I tried to tweak my autocomplete service to use the new "type" of "golf_course". It said it didn't exist. I will try again now and see if it's working. I wonder if there is maybe something else I am missing.

[Tigatok]

Yeah so, with the following code:

      const request: google.maps.places.AutocompletionRequest = {
        input: inputValue,
        sessionToken,
        region: "ca",
        types: ["pharmacy"],
        componentRestrictions: { country: ["ca", "us"] },
        bounds: map?.getBounds(),
      };

That will return Pharmacy results in my search. However, if I change that to "golf_course", I get the following console error:

If I inspect the Types I have to AutocompletionRequest, I see the following doc:

    /**
     * The types of predictions to be returned. For supported types, see the <a
     * href="https://developers.google.com/maps/documentation/javascript/places-autocomplete#constrain-place-types">
     * developer&#39;s guide</a>. If no types are specified, all types will be
     * returned.
     */
    types?: string[];

If you follow that link, it will bring you to the legacy place autocomplete. If you look on the left menu, there is a Places (new) api. So I am not sure if maybe its just places that isn't supported, or if I can somehow switch to that?

[usefulthink]

Yeah, the situation with the places API is very confusing at the moment. For autocomplete, a new version has just been published, see here and here. Those should also support the new place types (I have yet to test the new API)..

[shuuji3]

I found a similar report in the Issue Tracker: https://issuetracker.google.com/issues/321217616

There's no update yet but you can add "+1" to show interest to the Maps team.

[Tigatok]

So there is indeed some room for support, or the new stuff should be available? Just wanna make sure I understand where my position is.

Thanks again for the input!

[usefulthink]

As far as I understand it (I'm not a googler), the situation seems to be that google is in the process of rebuilding the places API services. Since the older API and it's JS client in the Maps JavaScript API is being relied upon a lot, they can't just change how the previously existing classes (Geocoder, PlacesService, AutocompleteService, etc) behave. Those will likely continue to talk to the old API endpoints. I'd assume they will be deprecated at some point in the future.

The new API started off as just the REST API (iirc the initial launch of the new Place class happened at the same time), and new functionality is being added to this new set of APIs. Those new APIs will be talking to the newer REST APIs exclusively.

So during this transition period, there will still be cases where the older API is a better fit, but as the new APIs are expanded over time this is going to be fewer and further between.