Spiderfier with sub sipiderfier when too many markers

[crismethods]

With the team I am working we have seen different behaviours using this library, not all of them part of what we expected, and we are wondering if it is a resource/performance issue when there are too many markers. For instance there are 104 markers in the same position, and the resulting behaviour is the one shown in the images attached in this ticket. This not always happen in the same way, sometimes the click shows only part of the markers in the Spider way, and if the Spiderfier is closed and then opened again it shows different amount of markers, any workaround for that when are too many objects?

Thank you!

[jawj]

Hmm — weird. I wouldn't have thought 104 markers would be too many. Are you using clustering too? And could you share some code where this happens?

[crismethods]

Yes, we are using clustering as well (previously MarkerclustererPlus and now gmap-marker-cluster), a piece of code is:

    this.markerClusterer.addListener("clusterclick", (cluster) => {
      let markers = cluster.getMarkers();
      if (this.markersSamePosition(markers)) {
        let last_marker = markers.slice(-1)[0];
        this.markerClusterer.setMaxZoom(15);
        this.map.setZoom(17);
        this.map.setCenter(cluster.getCenter());
        setTimeout(
          () => {
            Map.triggerEvent(last_marker, "click");
          },
          700
        );
      } 
     ...
     ...
    });

So basically our cluster doesnt respond to the default click but we implement our own. We have the situation that we could have many markers at the same location, so when that is the case, then we trigger the click on the last marker for that cluster, and then the Spiderfy is triggered. So we realised that the timeout is affecting the way the Spiderfier displays the markers, and 700 was the value where most of the time there were displayed correctly, but as you know playing with timers means depending on the client' side, just wondering if that could be a reason for that.

Thanks!