Cannot apply animation to overlay view

[joaoreynolds]

Unable to apply animation to OverlayViews because of remounting

Your Environment

os: mac

node --version: 10.13.0

react version: 16.9.0

webpack version: 4.39.2

@babel version: 7.5.5

@react-google-maps/api version: 1.7.5

How does it behave?

In this animated gif, the vehicle jumps around and the title flashes out and in again.

When a new array of "vehicle markers" is passed in and OverlayViews are rendered, the animation is broken (title fades back in, indicating a complete remounting of the element) and therefore the position is not animating either.

How should it behave correctly?

In this animated gif, you see the transition of position happens, with the animation and no flashing of the title.

I upgraded to react v16 and to @react-google-maps/api from react-google-maps v4.11.0. This second animated gif shows animations running smoothly under the old react-google-maps v4.11.0. I noticed animations broke down when I upgraded to react-google-maps v9.4.5 - but I can't identify what in the source code changed to prevent animations from working between rerenders.

Sample Code

Parent Component:

(A new array of filteredVehicles is passed in each time vehicle positions are updated)

  <LiveMap
          onMapMounted={this.handleMapMounted}
          googleMapApiKey={settings.googleApiKey}
          center={{latitude: settings.mapLatitude, longitude: settings.mapLongitude}}
          zoom={settings.mapZoomLevel}
          vehicles={filteredVehicles}
  />

Map Component

Calling the renderVehicles function in the children of GoogleMap (see next)

<GoogleMap
  mapContainerStyle={{ height: '100%', maxWidth: '100%' }}
  onLoad={this.handleMapLoaded}
  zoom={this.props.zoom}
  center={centerPoint}
  onZoomChanged={this.handleChangeZoom}
  options={mapOptions}
>
  {renderVehicles(this.props.vehicles)}
</GoogleMap>

renderVehicles()

This returns an array of OverlayViews, each having a key assigned to it.

export default(vehicles=[]) => {
  return vehicles.map((myVehicle) => {
    let position
    if(myVehicle.encodedMapPoint){
      const latLng = google.maps.geometry.encoding.decodePath(myVehicle.encodedMapPoint)
      if(latLng && latLng[0]){
        position = latLng[0].toJSON() //converts to {lat: <value>, lng: <value>}
      }
    }
    else if(myVehicle.latitude && myVehicle.longitude){
      position = {lat: myVehicle.latitude, lng: myVehicle.longitude}
    }

    return (
      <OverlayView
        key={myVehicle.vehicleId}
        position={position}
        mapPaneName={OverlayView.OVERLAY_MOUSE_TARGET}
        getPixelPositionOffset={getPixelPositionOffset}
      >
        <VehicleMarker
          heading={myVehicle.heading}
          isStopped={myVehicle.speed ? false : true}
        />
      </OverlayView>
    )
  })
}

I wish I could provide some ideas on how to fix this, but as I said, I don't have any. Thanks for taking over react-google-maps, by the way!

[JustFly1984]

@uriklar @FredyC

[danielkcz]

I don't follow. Do you have some animation in place or are you just expecting smooth transition between two supplied points? I think that's out of the scope of the library. Either you have to have a very detailed path of points (can be calculated) or take care of movement smoothing somehow (not sure how).

[joaoreynolds]

So, google calculates the top and left positions, and updates them when the lat lng changes.

So a transition is all I've added. As I said, older versions of react-google-maps didn't remount dom elements whenever new props were passed down.

Actually, aside from not being able to animate, performance is really bad as soon as I get more than about 30 OverlayViews on the map, things get really janky. So this might not actually be about animations, and maybe more about performance implications. So I think if dom nodes weren't remounted on each rerender, both my problems would be solved.

If supporting maps that have that many elements isn't actually part of the scope of this library, just let me know :)

[danielkcz]

Alright, in that case, it's more about #198 (comment).

@JustFly1984 Probably best to close that issue and track it in this one which is more on the point.

[JustFly1984]

closing an issue in favor to #198
Don't really have time to dig in this week, but if somebody want to fix and PR, you are welcome, I'll merge and upload new version