-
-
Notifications
You must be signed in to change notification settings - Fork 634
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Smooth virtual dom integration for html markers #4120
Comments
To be honest, I'm not sure I understand why this should be part of this library and not part if a wrapper that is using virtual dom. |
When doing frontend development with a vdom-based framework, it'd be very convenient if html-based maplibre markers were handled the same way elements in a list were. Due to maplibre re-mounting and mutating the marker dom nodes, vdom libraries I have tried do not interoperate smoothly.
There are workarounds such as just calling a
refresh
javascript function which manually deletes and inserts all the markers each time, and they work well enough in the short term, but if mapping is a significant portion of the application you lose a lot of the benefit of a vdom-based frontend framework.I could see a couple ways this could be implemented:
One is trying to get maplibre to minimize de-sync with the vdom (remounting, mutation etc.), such as allowing markers to be added simply by putting them as children of the map, with things like
data-
attributes for providing non-html maplibre-specific information like lat/long. This would likely be the most performant and clean, but may require more cooperation from the vdom library, as certain things liketransform
need to be edited without the vdom library necessarily being aware, so it may complain and try to get rid of them in the re-sync.Another approach would be allowing maplibre to tie into a user-specified "marker container", which instead of re-mounting it will simply sync with / clone elements out of, using things like
MutationObserver
, then users can simply throwdisplay: none
on this container so that it doesn't render twice. Again usingdata-
attributes or similar for specifying things like lat/long would be needed.The text was updated successfully, but these errors were encountered: