Conversation
|
Hi @GNURub could you explain a bit more of the use case for passing an already initialised Marker instance instead of just passing the marker options and having the Geocoder Control create it for you? |
|
I have a marker on the map, and I want to use this in the Geocoder Control, so I can pass the instance to it in the marker option. |
|
Okay, it does complicate things a bit more though, since currently the marker is managed internally by the GeocoderControl, if it's shared then what happens if the GeocoderControl has removed it but you still have the reference and try to use it? Vice versa you remove it but the GeocoderControl is still expecting it there? Then what's the expectation when you pass that existing Marker, should the GeocoderControl immediately remove it from the map, or leave it. It feels much cleaner to simply have the GeocoderControl use it's own private Marker, that way it has control over it. There's little benefit in "reusing" a marker, so shouldn't be an issue to let the GeocoderControl create a new one. If you really want to use your own marker, you could implement movement of it yourself via the events fired by the GeocoderControl. Anyway, just my initial thoughts, keen to hear what others think. |
The
option.markerparameter has the option of being a Marker instance.npm run docsand commit changes to API.mdmasterheading before merging