Comparison to Uber's react-map-gl

[z0d14c]

has anyone compared this to react-map-gl by uber?

if so, what were your findings?

for example we are skeptical of building the style object and passing it in to control everything instead of using the semantic style of this library. any and all thoughts would be helpful. sorry for hijacking the issues board, we hope to use this library if its appropriate for our needs (and would be contributing to it also).

[kitten]

@alex3165 started to work on this library since react-map-gl is just a really lean wrapper around mapbox-gl. This is why there are a couple of React-friendly abstractions in this library around layers, markers, popups, etc. We basically wanted to cover the 90% use case, that shouldn't require the user to write mapbox-gl code directly.

While this means that we sometimes have to implement new features as opposed to react-map-gl, this doesn't mean that you can't use them in a similar way. You still get access to the internal mapbox-gl map instance for instance.

react-map-gl brings a big feature of its own to the table: overlays. They have a lot of interfacing overlays for their map, that are relatively easy to use. We haven't implemented something like this here yet, but we're aware of it.

As you can see, the goals of the two libraries are quite different. I'm happy to give you more details on this, and I think @alex3165 can help you as well :)

[alex3165]

Hey @z0d14c to complete what @philpl said, this library aims to abstract Mapbox-gl features without using their API but only the component it is exposing from it (Marker, Layer, Feature, Popup ...) as opposed to react-map-gl which doesn't provide these components but give you overlays for data visualization purposes (ChoroplethOverlay, ScatterplotOverlay, DraggablePointsOverlay, SVGOverlay and CanvasOverlay) and many more using their library Deck.gl. I released an article explaining why I built react-mapbox-gl along with the first version of the library https://medium.com/@alex_picprod/an-efficient-webgl-map-with-mapbox-gl-js-and-react-mapbox-gl-4ac7f3d41570#.sbadubok7

[alex3165]

Also I recently merged a PR which include a component projected-layer which can be used to build many custom overlays. We can imagine a third library which use this projected-layer and provide different overlays for data visualization purposes as well.

Happy to hear the opinion of the community on this.

[z0d14c]

Thanks so much @alex3165 @philpl for the timely replies. We don't currently leverage too many of the mapbox-studio features per se other than using their base layers. What we do is add custom image layers and geojson polygons/polylines/markers on top of the mapbox vector base layer. Is react-mapbox-gl currently supportive of these features? If we absolutely have to, is it easy to access the MapboxGLJS instance? Thank you again :)

[alex3165]

Yes react-mapbox-gl support these features polygons, polylines and markers, you can have a look at this example: https://github.com/alex3165/react-mapbox-gl/blob/master/example/src/all-shapes.js which includes all the supported shapes.

And yes you can easily access to the mapbox instance, we pass the instance to every event, you also have an event at startup onStyleLoad which get the map instance as well as a first parameter

[z0d14c]

Thanks for your answers. I will close this question for now as you have been more than sufficient in responding to my concerns. I would say that it may be a good idea to have a FAQ question dealing with the comparison to uber's react-map-gl. Perhaps I or someone else can contribute to this in the near future.

[easherma]

https://medium.com/@alex_picprod/an-efficient-webgl-map-with-mapbox-gl-js-and-react-mapbox-gl-4ac7f3d41570 <-- link to article refrenced above

[derwaldgeist]

The articles mentioned above are pretty dated. Is there a more recent comparison table? We started with react-map-gl, but ran into quite some performance issues. Also, we're desperately needing cluster support, which react-map-gl does not offer out-of-the-box, and inertia panning, which I love about react-mapbox-gl.

On the other hand, we need some data visualization capabilities, like dynamically coloring countries or regions based on data (choropleth). I saw the comment on implementing this on top of projective-layers. Were there any follow-ups on this?

In a nutshell, I am wondering if we should switch to react-mapbox-gl - or even go for mapboxgl.js directly instead? It would be really helpful to have a kind of comparison section / table in the docs.

[mklopets]

@derwaldgeist dynamically coloring countries based on data should be simple with either lib – by plugging right into mapbox's native style API, with functions and whatnot.

Wondering what the performance issues were that you have run into? What kind of features are you using currently?

As for the original question, I don't know of a recent comparison doc.

[derwaldgeist]

Thanks for your fast response.

The performance is basically related to situations when there are a lot of markers visible on the map. Though we cache them and they are definitely not re-rendered, performance goes down drastically once the number exceeds 100 or so and try to pan the map.

The urbica library shows the same behavior, but we could solve it by using clusters (which is not directly supported by the uber library).

[mklopets]

@derwaldgeist what are you using the markers for? Markers are going to perform poorly on any mapbox wrapper/library. If you only need to display something like an icon or text, symbol layers are much, much more performant.

[derwaldgeist]

We're using markers, because each of them has to be clickable. Is this possible with symbol layers? I haven't found a sample for this yet.

[mklopets]

@derwaldgeist

Yeah, you don't need markers to make the map clickable. As a matter of fact, you don't even need to show anything on the map to make it clickable. Here's a related official example of reacting to clicks: https://docs.mapbox.com/mapbox-gl-js/example/queryrenderedfeatures-around-point/

The main gist is that when a click is detected, you ask mapbox for "what are the Features at that position that the user might have intended to click on?" and then get a list of features, from which you can find the intended one based on some logic, and then you can do whatever based on the click (show a popup, change some state, redirect etc).

[derwaldgeist]

Will this work for features we've added as a GeoJSON layer? In this case, this would be great. We're not interested in generic features (i.e. those which are part of the base map), as we're overlaying the map with additional information.

[mklopets]

Yes, queryRenderedFeatures can return features at some screen coordinate from any layer. If you have more questions, please open a separate issue.