-
Notifications
You must be signed in to change notification settings - Fork 1.4k
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
Please sit around a table and talk #451
Comments
@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. |
Hey @ibgreen, Thanks :)
True. I'm going to open something there.
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.
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 ? |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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 :
Same issue duplicated :
The text was updated successfully, but these errors were encountered: