Smooth virtual dom integration for html markers

[tysonzero]

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 like transform 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 throw display: none on this container so that it doesn't render twice. Again using data- attributes or similar for specifying things like lat/long would be needed.

[HarelM]

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.
Much like other controls like geo location, navigation etc, this library is offering a ready to use controls, written in pure JavaScript/html/css, that can be used out of the box for easy setup and to accommodate the common scenarios.
For things that need extra care, one could roll out their own control.
I even thought about removing the UI controls from this library and offer them as an auxiliary package, but it didn't offer a lot of value in terms of bundle size and did complicate the initial setup for new users.
You could implement it as a plugin/additional npm package to be used by who ever needs this extra smoothness for virtual dom framework.
Moreover, I'm guessing you are referring to react, and for that there's a very good wrapper that is well maintained that can probably benefit from your experience and this specific addition.