Skip to content
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

Add widgets prop to Deck class #8023

Merged
merged 8 commits into from
Aug 15, 2023
Merged

Add widgets prop to Deck class #8023

merged 8 commits into from
Aug 15, 2023

Conversation

chrisgervang
Copy link
Collaborator

@chrisgervang chrisgervang commented Jul 25, 2023

For #7946

Background

To build any widgets we'll need some interface in Deck to add them. This adds a declarative interfaces to the Deck API for applications to add/update/remove widgets.

Note: This PR adds a private imperative "addDefault" similar to EffectManager so that the tooltip widget isn't affected by an application. There is ongoing discussion around a public imperative interface.

Change List

  • Add widgets prop to Deck for declarative use cases.
  • Adds private useDefault function to WidgetManager to maintain tooltip functionality
  • Simplifies WidgetManager "add widget" interface by adding placement and viewId as widget members.
  • Updated docs

@coveralls
Copy link

Coverage Status

coverage: 89.85%. remained the same when pulling fc6be2c on chr/deck-widgets-prop into f368dea on master.

Copy link
Collaborator

@Pessimistress Pessimistress left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The list needs to be deep compared in every setProps call. See implementation of the EffectManager.

@Pessimistress Pessimistress changed the title add(deck) _widget prop Add widgets prop to Deck class Aug 3, 2023
Copy link
Collaborator Author

@chrisgervang chrisgervang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @Pessimistress for adding the declarative and imperative functions. Are there any caveats? Also, what do you think about adding a removeDefault with this design?

modules/core/src/lib/widget-manager.ts Outdated Show resolved Hide resolved
modules/core/src/lib/widget-manager.ts Show resolved Hide resolved
for (const id in this.containers) {
this.containers[id].remove();
}
}

add(
// Imperative API, not affected by the declarative prop
addDefault(
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can an imperative user call this to add a widget in their application?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not exposed right now, we need an overall strategy for imperative APIs (layers, views, effects, widgets).

Comment on lines 9 to 11
this.id = props.id;
this.viewId = props.viewId || null;
this.placement = props.placement || 'top-left';
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, weather or not to include these members as props would be case-by-case. For instance, doesn't make sense for tooltip to have a placement prop.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if the meaning of these constants can be extended, but tooltips could be positioned relative to the cursor.

Copy link
Collaborator Author

@chrisgervang chrisgervang Aug 6, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The placement for that use-case would still be "fill" I imagine, since it can still be anywhere in the map container. Marker would use the same placement, and also wouldn't expose container placement.

I'd imagine positioning relative to cursor would be internal to the widget.

widgetManager.add(widgetB, {viewId: 'map', placement: 'bottom-right'});
t.is(widgetManager.widgets.length, 2, 'widget is added');
t.is(widgetB._viewId, 'map', 'view id is assigned');
const widgetB = new TestWidget({id: 'B', viewId: 'map', placement: 'bottom-right'});
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this API change. Having placement and viewId on add didn't make sense.

modules/core/src/lib/deck.ts Show resolved Hide resolved
@@ -988,7 +992,7 @@ export default class Deck {
deck: this,
parentElement: this.canvas?.parentElement
});
this.widgetManager.add(new Tooltip(), {placement: 'fill'});
this.widgetManager.addDefault(new Tooltip());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Is there any way to avoid addDefault()? Such "global" registration is usually best avoided if possible. Can the tooltip be added when it is actually used?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'd want to consider if changing it could break something since the 8.9 and prior always adds a tooltip to the container.

modules/core/src/lib/widget-manager.ts Show resolved Hide resolved
lastViewports: {[id: string]: Viewport} = {};

/** Widgets added via the imperative API */
private defaultWidgets: Widget[] = [];
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe the names could be more reflective of the comments - imperativeWidgets / declarativeWidgets / allWidgets etc?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes maybe.. there's ongoing discussion in a new RFC on what our imperative API could be.

modules/core/src/lib/widget-manager.ts Show resolved Hide resolved
// widget already added
return;
/** Imperative API. Widgets added this way are not affected by the declarative prop. */
addDefault(widget: Widget) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was about to suggest a different name, but I guess this was renamed to addDefault based on previous comments.

Comment on lines 9 to 11
this.id = props.id;
this.viewId = props.viewId || null;
this.placement = props.placement || 'top-left';
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if the meaning of these constants can be extended, but tooltips could be positioned relative to the cursor.

@chrisgervang chrisgervang merged commit 1d56226 into master Aug 15, 2023
2 checks passed
@chrisgervang chrisgervang deleted the chr/deck-widgets-prop branch August 15, 2023 19:28
Pessimistress added a commit that referenced this pull request Aug 24, 2023
---------

Co-authored-by: Xiaoji Chen <cxiaoji@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants