PlacesService / useMapsLibrary getDetails Inconsistencies & updated documentation

[spenserschwartz]

Two points in one post since they are likely connected behind the scenes:

useMapsLibrary documentation/example

For the Using Other Libraries of the Maps JavaScript API section, the setPlacesService(new placesLib.PlacesService()); line needs an argument or everything errors out (screenshot of error included). I've been using to some success:

const div = document.createElement("div");
setPlacesService(new placesLib.PlacesService(div));

placesService getDetails Inconsistencies

Since I'm unsure if we're implementing the custom code above correctly, I can imagine this may be part of the problem as well. This is a bare bones example implementing getDetails from PlacesService where the PlaceResult returned from Google's API is inconsistent. Saving the file and having it updated in dev will return all results, but eventually it seems to eliminate these fields from PlaceResult: rating, reviews, user_ratings_total.

• In the code, see the fields line where you can update which fields are seen. Updating/saving this line will fix the issue for some time, but eventually goes back to omitting some fields that definitely exist.

What I've tried for debugging: sessionToken, hardcoding a placeId like Big Ben that has thousands of ratings to show inconsistency so we don't incorrectly surmise that it's a bad placeId (Big Ben sometimes has these fields, sometimes does not, but have tried with dozens of other popular places)

const BasicComponent = () => {
  const placesLib = useMapsLibrary("places");
  const [sessionToken, setSessionToken] =
    useState<google.maps.places.AutocompleteSessionToken>();
  const [placesService, setPlacesService] = useState<PlacesService | null>(
    null
  );

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

    // Correctly initializing PlacesService with a div element, maybe
    const div = document.createElement("div");
    setPlacesService(new placesLib.PlacesService(div));

    setSessionToken(new placesLib.AutocompleteSessionToken());
  }, [placesLib]);

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

    // const placeId = "ChIJ2dGMjMMEdkgRqVqkuXQkj7c"; // Big Ben
    const placeId = "ChIJN1t_tDeuEmsRUsoyG83frY4"; // Google Sydney office from Google docs online example
    const request = {
      placeId: placeId,
      fields: ["ALL"], // change this and save to sometimes get different results
      sessionToken,
    };

    // Using the placesService to fetch details
    placesService.getDetails(request, (result, status) => {
      if (status === google.maps.places.PlacesServiceStatus.OK && result) {
        console.log("Place details:", result);
      } else {
        console.log("Failed to fetch place details:", status);
      }
    });
  }, [placesService, sessionToken]); 

  return <div>SplashComponent</div>;
};

export default BasicComponent;

[spenserschwartz]

Updated Information (NOT A SOLUTION)

I believe that there is something legitimately inconsistent with Google's API. I have set up the Place Details API as well through both a router and also using the CURL query and the results are the same. The screenshot shows how you can get differing results just minutes apart for the same request. This is just analysis and I would rather be shown how I am wrong because I'd rather this work.

• Smaller attractions seem to be more consistent. Taco Bell or a small museum seem to always work, but Big Ben, Sydney Opera House, Chrysler Building, Eiffel Tower have all remained inconsistent.
• Region does not seem to be the issue. I am based in the US and have not altered any regional settings. Domestic and foreign places have both been inconsistent.
• Changing the fields setting seems to trick the query into giving all results for an abstract limited time, but will eventually fail.

[usefulthink]

You are correct about the first part, I completely forgot about the attribution container being required when writing the docs.
Creating an empty div as attribution container is definitely something I have seen done, but I'm not really sure if there are circumstances where it is legally required to have that element visible. If you have a map instance anyway, it could be a good idea to just pass that into the places service to be sure.

As for the inconsistent places results, that is an interesting observation, but ultimately nothing we have any influence over.
Maybe @wangela can have a look at why the places-api is leaving those properties out for some responses?

[usefulthink]

meanwhile, I updated the documentation to include the required parameter.

If I read the documentation about attributions correctly, it is officially required that you render the attribution container somewhere if you are using the PlacesService without a map.

[spenserschwartz]

Thanks for looking into this 👍 I'll mark this as answered since (as you said) the other issue is not your influence.

If @wangela does follow up on the inconsistent places results, I'll be happy to share/show the inconsistencies with the Google API calls with strong support that the problem lies with the actual source. The problem continues into both Place Details and Place Details (New).

The only call that I've found to reliably get ratings, user_ratings_total, and other missing fields is the original Places Text Search. Obviously this is not what would be recommended; since you aren't searching by id and may have to do 2 separate fetches to two different APIs for what should take 1 call, however this is the workaround that I'm using right now.

[usefulthink]

You can also create a ticket in the maps platform issue tracker about this. Sounds very much like a bug.

[spenserschwartz]

Ticket created