Expose idleListener as a method or property for toggling automatic render

[TheAtomicOption]

trafficstars

Currently idleListener is a protected property, so markerclusterer instances always call render() on map idle events whenever attached to a map. However sometimes this behavior isn't desirable. With large datasets rendering can take significant resources so users may wish to debounce this event or otherwise only call render() at their convenience. Rendering may also be pointless if the application is always going to change the marker data based on the new map location anyway, which is my current use case.

Describe the solution you'd like Export a method to toggle automatic calls to render() by remove()ing or reinstating the MapEventListener at idleListener, or export a property which the body of idleListener uses to determine whether to abort before calling render().

I'm willing to make a pull request for this. see: (https://github.com/TheAtomicOption/js-markerclusterer/commit/7e1a90706274bfa731d75413df84169b3bac465f) as a first draft.

**Describe alternatives you've considered Additionally/alternatively add a MarkerClustererOptions value to configure whether idleListener is assigned. This would at least allow it to be set on initialization, but users would have to write and manage their own listeners for calling render() rather than just calling a method to swap behavior.

Additional Context My particular use case involves retrieving a new marker list whenever the map pans or zooms. I'm using this module along with the rest of google maps through a wrapper for Blazor, called BlazorGoogleMaps (https://github.com/rungwiroon/BlazorGoogleMaps). Unfortunately this means that there is some lag between the between the business logic and JS. Because of that, alternatives like destroying the current instance of markerclusterer on map events before idle and instantiating a new one with the new data afterwards is difficult to work around. They can easily result in race conditions when things like calls to render from the idleListener can happen before my business logic has had time to respond.

The mediocre workaround I am currently using is to set a listener on the bounds_changed map event to call clusterer.clearMarkers(true) which at least avoids rendering the current set of markers until the next set of markers are added. But it's not optimal since I have to pass the entire marker set back into markerclusterer rather than being able to update it addMarkers()/removeMarkers()

[bdcoder2]

Have you considered trying Grid Clusterer?. It would give you the flexibility to add / remove data points and redraw on whatever event you choose.

[TheAtomicOption]

@bdcoder2 I don't think that is a good option. Grid Clusterer is a brand new project with a very poorly organized looking repo, with no commits in the last few months (appears inactive after the initial flurry at its creation in Dec.). It would require rewriting parts of the Blazor wrapper to accommodate. It isn't recommended/supported by Google, and if the name/screenshot is anything to go by it is using a simple grid algorithm for clustering which is not what my use case requires, nor fitting for the wider set of use cases intended to be supported by the Blazor wrapper.

For those reasons, if I were to use a non-standard/unsupported module, I'd just use a private fork of this repo with the idleListener exposed as a public property.

[bdcoder2]

@TheAtomicOption - No problem, was just trying to provide other options...

It is unfortunate that the original (and current) clusterer implementations chose to use the Marker as the underlying data structure; the Grid Clusterer is up to 90% faster (during data point creation) and can easily handle millions of data points and offers many of the features being requested.

Perhaps when I find more free time, I will try to update the “very poorly organized looking repo”.

[TheAtomicOption]

This is getting off the topic of this issue, but it's faster because it doesn't do the same thing. The old MarkerClustererPlus was also faster for a similar reason. Seeing as that's your repo, my recommendations are: 1. take the files out of the zip so people can look at them online. 2. update the readme to show example usages and any configuration options it has. 3. maybe have a couple sentences at the top of the readme explaining why you think the module has a niche official options for clustering can't/don't fill.

Thanks for trying to help, but please do not reply further about your module in this thread as it's off topic to my feature request.