usefulthink
commented
10 months ago I really like the Idea here. But I don't think this is a feature I'd want to add for the 1.0 version.
I think you can already get pretty far using just the AdvancedMarker component. I'd need a bit of fiddling around to see how exactly, but it can render arbitrary components via portals at specific coordinates on the map (the specified coordinates will always map to the bottom/center of the child-element). The two biggest differences between advanced markers and custom overlays based on OverlayView are that advanced markers participate in the collision handling algorithm and that custom overlays will also work on maps without a mapId.
With that said, I would love to see a good abstraction for a custom OverlayView, maybe a component (OverlayView, MapOverlay or something like that). So basically the component you described, but with a more generic name :)
I would be very happy to work with you on this.
If you want to start exploring this for yourself, examples of how the portals can be used can be found in the MapControl and AdvancedMarker components (the new react-docs are an awesome resource as well).
We've had discussions about this in our company recently and came to the conclusion that a good infowindow implementation would be too complex for this library and more deserving of a library of its own. To explain this a little further:
The behaviour of a good infowindow is a lot more complex than just placing html on a map
- infowindows are mostly placed relative to some marker, and the positioning and size of that marker has to be taken into account when positioning the infowindow. Google Maps always places them on top, mapbox varies the positioning based on available space)
- infowindows should have a way to ensure they are fully visible when opened. Google Maps does this by panning the map, in mapbox the infowindow sticks to the side of the map-canvas closest to the marked position if that position is outside the visible reagion
- another issue is the behaviour on mobile, where a larger infowindow will often cover most of the area available for the map which is bad UX, and a good infowindow implementation would provide alternative display modes for these situations
- and finally, UI elements in general are subject to all sorts of very subjective and opinionated design- and UX-questions and follow-ups like themeability, styling and such that I think are better done in separate libraries working with @vis.gl/react-google-maps
Tak1za
alexqhj
niranjan404
Target Use Case
The current infoWindow class doesn't allow for granular control over styling or even the close button. Having an infoWindow that can render a React.ReactNode (or even a static HTML element but the dev would have full control of it as opposed to what you get from infoWindow) would allow for making maps that look and feel much cleaner with the rest of the web app.
Proposal
I have implemented a Custom Info Window by extending the google.maps.Overlay class but I was only able to make it render static HTML elements, not React components. Maybe the use of React portals to render React components would work? I haven't tried it yet myself.
Or maybe this is the completely wrong approach and there's a better way of doing it.