feat(core, widgets): Allow widgets to modify views #9572
Conversation
ibgreen
force-pushed
the
ib/filter-views
branch
from
712eb53 to
c93bf41
Compare
| if (view1Index !== -1 && view2Index !== -1) { | ||
| views = [...views]; | ||
| const [viewProps1, viewProps2] = getViewPropsForSplitRatio(this.splitRatio); | ||
| views[view1Index] = cloneView(views[view1Index], viewProps1); |
There was a problem hiding this comment.
Why not add clone() to the View class, for consistency with Layer`?
There was a problem hiding this comment.
Why not add clone() to the View class, for consistency with Layer`?
Yes, that would be the "natural thing" to do. But for the purposes of keeping this PR small and attract as few tangential discussions as possible, I left that our for now.
Added a TODO comment.
| this._widgetManager!.setNeedsRedraw('SplitterWidget'); | ||
| }; | ||
|
|
||
| filterViews(views: View[]): View[] { |
There was a problem hiding this comment.
To contrast with thelayerFilter API which is Layer => boolean, I wonder if this pattern is too powerful. If this function is implemented to add a view on every frame, will that make the number of view grow indefinitely?
There was a problem hiding this comment.
wonder if this pattern is too powerful. If this function is implemented to add a view on every frame, will that make the number of view grow indefinitely?
- As you can see it replaces the existing views created by the app with clones, it does not add views.
- If a widget wanted to add a view, it would do so with a specific id, and check for the presence of that id and only add if not already present.
- This setup does not add a view / filter views every frame. When the ratio changes, a flag is set that is cleared after the filtering is done.
ibgreen
force-pushed
the
ib/filter-views
branch
from
54b004d to
c30e62c
Compare
There was a problem hiding this comment.
The majority of these changes are an easy stamp but of course this is the interesting one to discuss:
Hook widgets into the deck.gl needsUpdate cycle
Is this an ordered cycle, and if so, where is widgets in relation to other updates?
Are there any environments, like Mapbox integration, where this breaks?
If it's the last update in the cycle, does that mean the widget code gets the "final say" on state?
| @@ -33,6 +35,7 @@ export abstract class WidgetImpl<PropsT extends WidgetImplProps> implements Widg | |||
| this.props = props; | |||
| } | |||
|
|
|||
| onWidgetInitialized(): void {} | |||
There was a problem hiding this comment.
It'd be useful to add a lifecycle hook to the core widget interface that gets called by the manager after the widget is added to the DOM.
The existing hook, onAdd, is called prior to DOM mount, which makes sense but is quite limiting to the theme widget in particular since the widget needs to initialize its theme after it's mounted to the DOM (since it's a DOM mutation).
While this splitter widget isn't mutating the DOM, it seems the spirit of onWidgetInitialized is the same.
Closes #
Background
Change List