Please sit around a table and talk

[cyrilchapon]

• https://github.com/AlpacaTravel/react-map-gl-alt
• https://github.com/uber/react-map-gl
• https://github.com/alex3165/react-mapbox-gl

Both MapboxGL.js and React are 4 years old. There are currently 3 different, active and maintained, libraries out there trying to implement a React friendly API for Mapbox. While each of them is pretty great and hard work, each of them lack features. When coming from a raw MapboxGL.js background, new to react, this is pretty critical and hard to make a reliable choice. I guess coming from a React background and discovering MapboxGL and making the same choice is also hard.

This seems pretty much complicated, as governance, paradygms, workflows and many stuff are different in each of the repos. But it also feels like there is so much relevant and valuable thing to do with all that hard work, than 3 different and incompatible libraries..

The beauty of opensourcing is that everything is possible, isn't it ? So hey, what about sitting around a table and talking ?

Related :

• Use of queryRenderedFeatures for hover/click events etc. - possible to expose? #87
• Unable to use react-map-gl in create-react-app  #176
• Comparison to Uber's react-map-gl alex3165/react-mapbox-gl#97

Same issue duplicated :

• Please sit around a table and talk AlpacaTravel/react-map-gl-alt#16
• Please sit around a table and talk alex3165/react-mapbox-gl#511

[ibgreen]

@cyrilchapon Good initiative, thanks for starting the discussion.

First thought, perhaps the mapbox team should be invited to this table, after all they have left the task of creating react wrappers for their product to the community, they benefit from the existence of these wrappers, and they could turn this situation upside down at any time should they choose to release their own wrapper.

Also alignment may not be all that easy. I can't speak for the other frameworks but one challenge is that react-map-gl's goal isn't necessarily to provide a perfect mapbox-gl wrapper, exposing all mapbox features etc.

From our perspective we need a react wrapper that works really well with our deck.gl framework, which requires a things like a completely "stateless" rendering model (e.g. no mapbox controlled "flyTos"), and the ability to continue interacting even when mapbox-gl can no longer display the map (e.g. pitch > 60).

This involves reimplementing large parts of mapbox event handling, transitions etc. and makes things a lot more complicated than they need to be in other wrappers. Supporting our requirements would probably be overkill for the other teams. Even internally we have occasionally have lively debates about the merits of different approaches and find it hard to align all opinions :)

So, with that little caveat, we are open to discussion.

[cyrilchapon]

Hey @ibgreen,

Thanks :)

perhaps the mapbox team should be invited to this table, after all they have left the task of creating react wrappers for their product to the community, they benefit from the existence of these wrappers, and they could turn this situation upside down at any time should they choose to release their own wrapper.

True. I'm going to open something there.

we [...] require a things like a completely "stateless" rendering model

From a neophyte point of view like mine, this doesn't seems to be an obstacle, but more like a react (redux ?) good practise you decided to follow; which indeed become ambitious when talking about mapping. Philosophically, this is just going "declarative" style when coming from "imperative" background. The fact to require and expose a "declarative-only" API, mapping to some "imperative" stuff (like setStyle, mergeStyle, flyTos and stuff) (I didn't digg into uber's code, but I just can't believe you managed to render something without calling a single imperative function from mapboxgl), is something one basically need and expect from a decent React wrapping APIs, I guess.

From our perspective we need a react wrapper that works really well with our deck.gl framework
This involves reimplementing large parts of mapbox event handling, transitions etc. and makes things a lot more complicated than they need to be in other wrappers.

What about thinking of an approach involving a common pedestal, much simpler, and designing it with combatibility in mind, with another module that would bridge between this pedestal and deck.gl ?

EDIT: Furthermore, something like panning over 60 seems like a mapboxgl extension, and not part of any react-specific stuff. Doesn't it ?