Support for Places API (New)

[jz-notion]

Is your feature request related to a problem? Please describe.
Google Maps launched a new Places API along with updated pricing structure. The previous API is now marked as Places API (Legacy). This loader does not appear to support the new API & features.

• Migration guide: https://developers.google.com/maps/documentation/places/web-service/migrate-overview
• New pricing: https://mapsplatform.google.com/resources/blog/build-more-for-free-and-access-more-discounts-online-with-google-maps-platform-updates/

Describe the solution you'd like
Please add support for Places API (New).

Describe alternatives you've considered
Integrate with the new API directly.

[usefulthink]

There is nothing for us to do to support those new APIs, the classes used to interact with the new APIs share the places library in the Maps JavaScript API with their older counterparts.

As far as I know, the maps team is in the process of rebuilding the Places API Services and corresponding JS classes.
Since the older API and its classes (Geocoder, PlacesService, AutocompleteService, etc) are being relied upon a lot, they can't just change how those classes behave. They will likely just continue to talk to the old API endpoints. I would assume they will be deprecated at some point in the future.

The new API started off as just the REST API (iirc, the new Place class was published at the same time). New functionality is being added to this new set of APIs (for example the AutocompleteSuggestion class). Those new APIs will be talking to the newer REST APIs exclusively. But all of that is happening in the same google.maps.places namespace.

[NoLevL]

But if the API's are switching from being GET to being POST, why is there not something you can do? The deadline for when the Places API (Legacy) is officially deprecated was 1st of March.
Together with that the API calls have changed how they are being called the URL also differ from the Legacy API.

• Changes: https://developers.google.com/maps/documentation/places/web-service/migrate-autocomplete

Would be really nice to have the package be compatible with the new and updated API along with updated pricing structures. Just as mentioned by @jz-notion.

Otherwise we would have to move from this package and integrate with the API directly.

[usefulthink]

I don't know what else to tell you. This loader is 100% "compatible" with the new places API, meaning you can choose to use either the legacy or the new places library – both versions exist together in the places library that can be loaded via loader.importLibrary('places').

It's on the application developers to actually use the new API – that is not going to happen automatically, since it requires developers to use completely different classes (for example using google.maps.places.AutocompleteSuggestion instead of google.maps.places.AutocompleteService for autocomplete).

Here is an article detailing the migration process from legacy to new places API: https://developers.google.com/maps/documentation/javascript/places-migration-overview

Is there anything else I can do to clear that up?

[NoLevL]

That actually clears up quite a bit, thank you. The documentation is not super clear on how to migrate to the new version using classes.

Thanks for clearing up the misunderstanding, my intent was not for me to be able to do nothing and for you to solve the "problem".

[nbyloff]

I have issue with the actual API not working for me at all. I documented it here and someone in the comments said it's broken for react js loader as well. Can anyone confirm it's broken for them as well? Or is my example incorrect?

https://stackoverflow.com/questions/79482008/google-places-api-new-autocomplete-not-working

Example code from above thread

import { Loader } from '@googlemaps/js-api-loader';

const loader = new Loader({
    apiKey: 'MY_API_KEY',
    version: 'beta', // weekly, alpha or beta (none work completely)
    libraries: ['places'] // should I do this or import library below?
});

async function initMap() {
    // Request needed libraries.
    const [{ Map }, { AdvancedMarkerElement }] = await Promise.all([
        loader.importLibrary("marker"),
        loader.importLibrary("places"),
    ]);
    // Initialize the map.
    map.value = new google.maps.Map(document.getElementById("map"), {
        center: { lat: -34.397, lng: 150.644 },
        zoom: 9,
        mapId: "4504f8b37365c3d0",
        mapTypeControl: false,
    });

    let placeAutocomplete =
        new google.maps.places.PlaceAutocompleteElement({
            componentRestrictions: {country: ['us']},
        });
    placeAutocomplete.id = "pac-input";
    let card = document.getElementById("pac-map");
    card.appendChild(placeAutocomplete);

    placeAutocomplete.addEventListener('gmp-placeselect', async ({ place }) => {
        console.log(place);  // NEVER MAKES IT HERE IN ALPHA
    });
}

onMounted(async () => {
    initMap();
});

[usefulthink]

@nbyloff Please note that all web-components are all still in alpha/beta and not yet in the stable version.

Here are a couple of notes to help you fix your problem (also a working example):

• there was a change in the alpha channel regarding how the selection is handled, there no longer is a gmp-placeselect event and instead a gmp-select. (see the deprecation note here: https://developers.google.com/maps/documentation/javascript/reference/places-widget#PlaceAutocompletePlaceSelectEvent). The recommended way to handle this is something like this:

  async function handlePlaceSelected(place) {
    await place.fetchFields({fields: ["displayName", "formattedAddress", "viewport"]});
  
    map.fitBounds(place.viewport);
  }
  
  // beta channel
  pacEl.addEventListener("gmp-placeselect", async (event) =>
    handlePlaceSelected(event.place),
  );
  
  // alpha channel and upcoming stable version
  pacEl.addEventListener("gmp-select", async (event) =>
    handlePlaceSelected(event.placePrediction.toPlace()),
  );

• if you use await loader.importLibrary('places'), you don't need to use the libraries in the loader constructor. But it also doesn't hurt to have both.

• the destructuring in the example is wrong, it should be more like this:

  const [{ Map }, { AdvancedMarkerElement }] = await Promise.all([
      loader.importLibrary("maps"),
      loader.importLibrary("marker"),
      loader.importLibrary("places"),
  ]);

  then again, you're not using the destructured names, so it could be simplified to just

  await Promise.all([
      loader.importLibrary("maps"),
      loader.importLibrary("marker"),
      loader.importLibrary("places"),
  ]);

• (if you're using typescript) I just noticed that there are some problems with the @types/google.maps package:

  • The type for importLibrary('places') doesn't contain PlaceAutocompleteElement (which exists in reality), so this is needed:

    // @ts-expect-error TS2339: Property 'PlaceAutocompleteElement' does not exist on type 'PlacesLibrary'.
    const { PlaceAutocompleteElement } = await loader.importLibrary("places");

  • the type of google.maps.places.PlaceAutocompleteElement doesn't have an optional argument.

[nbyloff]

@usefulthink Wow thanks for pointing that out. Can't believe there's only an alpha version and they already disabled generating legacy keys for the old API. But I am catching the proper event on alpha version now!

Going to test a handful of other places API calls now, I might have to wait until there's a stable version. Thanks again!

[usefulthink]

I think the new Autocomplete Data API should already be out of beta. So you could use that to create an Autocomplete widget in your framework of choice yourself.