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
Implement Mapbox custom layer API RFC #2306
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's discuss the RFC before closing on this.
modules/core/src/lib/deck.js
Outdated
@@ -471,7 +473,7 @@ export default class Deck { | |||
}); | |||
|
|||
// Note: avoid React setState due GL animation loop / setState timing issue | |||
this.layerManager = new LayerManager(gl, {stats: this.stats}); | |||
this.layerManager = new LayerManager(gl, {stats: this.stats, deck: this}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the surface, this coupling is obviously very undesirable. Having two components that both know about each other breaks encapsulation and usually causes pain down the road.
Part of the problem is calling it deck
. Normally it is better to just allow the lower level component (LayerManager
in this case) store an 'unspecified' reference to the owning object, that can only be interpreted by higher layers.
Maybe the right approach is to reconsider who owns the context
. With the emergence of Deck
, ViewManager
etc classes we have already removed a lot of functionality out of LayerManager, and I my thinking has been that it should be further "gutted" to just handle layer matching. drawing/picking for instance really doesn't need to be placed in LayerManager
f8f7726
to
94e6dea
Compare
94e6dea
to
9a3c359
Compare
modules/mapbox/src/deck-utils.js
Outdated
offsetCenter: event.point, | ||
srcEvent: event.originalEvent | ||
}); | ||
callback( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Can we avoid nested functions?
Add a bit more explanation in the header about why this is done (picking...).
modules/mapbox/src/deck-utils.js
Outdated
pointerleave: deck._onPointerLeave | ||
}); | ||
deck.eventManager.on({ | ||
click: event => handleMouseEvent(event, deck._onClick), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Call it handlePickingMouseEvent
or something that hints at what it does?
onAdd(map, gl) { | ||
this.map = map; | ||
this.deck = getDeckInstance({map, gl}); | ||
this.deck = getDeckInstance({map, gl, deck: this.props.deck}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Storing _deck
on the map could avoid having to pass deck around like this...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is for the use case where we add a MapboxLayer
referencing a layer from an existing Deck
instance:
new MapboxLayer({id: 'my-layer', deck});
For #2132
Background
API proposal to provide a path for deck.gl pure-js and React users to use Mapbox custom layers. This change allows user to leverage deck.gl top-level API such as
pickingRadius
,onLayerHover
etc.Example:
Change List