POC: PopupWidget

[felixpalmer]

Background

Working on #8956 got me thinking whether it would be useful to add a PopupWidget. We would likely want to provide the same API eventually as in getTooltip, I've just implemented the textoption here

Change List

• Add PopupWidget
• Modify widget example to include popup

[ibgreen]

Minor nit: Maybe call this a POC rather than an RFC?

Can we articulate the main advantages of PopupWidget compared to Deck's current tooltip prop?

• Aligning all HTML generating code under widgets seems like one such advantage...
• What else? Theming?

Is this widget strong/complete enough that we would be able to consider deprecating the Deck.tooltip prop in favor of this widget?

Add the doc page for this widget would be a good way to advance this to next stage (once you have made sure there are no vetoes / strong objections).

[ibgreen]

Should the PopupWidget just take a callback instead, so we don't need to mess with it like this?

[felixpalmer]

Can we articulate the main advantages of PopupWidget compared to Deck's current tooltip prop?

@ibgreen getTooltip on works on hover, and we can only ever have a single popup. I note that in many of our examples we use alert() to demonstrate how to how to handle onClick but nobody is going to do this in practice and it forces our users to figure out how to handle this common scenario.

The elephant in the room is definitely the API misalignment with getTooltip. Choices:

• A) Scrap the PopupWidget and instead add getPopup.
• B) Remove getTooltip and document how to use it with PopupWidget (significant breaking change). In this POC it is sufficient to replace onClick with onHover and we have a tooltip!
• C) Live with the difference, justified by the fact that getTooltip needs to render on hover and thus should be outside the full rendering loop

I'm leaning towards option B. Note that deck is already basically doing this and I've just realized that I've basically reimplemented Tooltip 👀

[chrisgervang]

Another point towards C & A is state management. In these, tooltip state is managed by deck for convenience and practicality. I'm pretty sure the python and declarative json environments rely on internally managed state, in particular.

I like the unification offered by B), so I think we'd just need a solution for python and weigh the tradeoff of making tooltips harder to get started with by removing the managed version.

[ibgreen]

• I also like option B. Can it be gradual (i.e. we deprecate getPopup()) or would we need to break apps?
• Making sure widgets work in Python would be a strong acceptance criteria for me. The Python users can't easily create their own UIs on top of deck, so any widgets we can provide are extra valuable to this community.

[chrisgervang]

The widget manager has an imperative API... could this be made accessible to python all users not only for tooltips, but other stateful widgets as well? Is that all that Tooltip needs to be internally managed? It's currently added by default with this API already.

[Pessimistress]

A real "popup" widget will be expected to:

• control placement relative to the anchor, or automatically positioned to fit in the map container;
• have a tip that points to the anchor, like that from Google Maps or Maplibre;
• can render multiple instances on map with the correct z order;
• have a close button and/or closes when clicked outside;

The built-in tooltip in Deck is supposed to offer convenience but only the minimal functionality. While I'm fine with this simple initial implementation of a PopupWidget, it doesn't mean they are the same thing.

[chrisgervang]

I'd like to use CSS variables and add theming for these. --popup-background and --popup-padding could be good here, though I might want to go further and suggest to incorporate other aesthetics like a shadow and inner/outer stroke like the other widget designs. Reason being we can offer an appealing OOB design, and make it easy to customize with vars to match a user's design system.

My approach has been to put styles that aren't 100% necessary for functionality in the stylesheet and theme examples in here.

[chrisgervang]

A broader question since we have eye balls on widgets.. How should we handle if this has been added to no specific viewport, and there are multiple viewports? This remains an unsolved question in all of our viewport-dependent widgets. Currently, only the last viewport in the list will get the popup even if the position is visible in multiple viewports.

I wonder if we a widget should be able to return multiple UI elements if there are multiple viewports around L66 in onAdd? Or if there should be some warning or documentation to say "you're using multiple viewports, so you should instantiate a widget-per-viewport and supply viewId"