feat(core): Add container to WidgetProps

[Pessimistress]

Background

widget.viewId is currently overloaded with two purposes:

• Functionality - defines the view(port) that the widget interacts with. A widget does not receive viewport update events from unmatched views if viewId is specified.
• Layout - defines the bounding box that the widget is positioned relative to.

The above two are often the same, but not always. This PR proposes a new prop so that the user can specify the two separately. When not provided, container falls back to viewId which is consistent with the existing behavior.

Change List

• Add container to WidgetProps
• Docs

[chrisgervang]

Lgtm! I like how the manager handles the custom container as opposed to the widget itself needing to be concerned with which element it's appended to.

What about CSS? It's possible some selectors weren't written with an external container in mind, and the user will need to add some classes to their container

[Pessimistress]

What about CSS?

Each widget's root element (attached to the external container in this case) has the deck-widget class. A quick glance at the source, all CSS rules are nested under this class. There does not seem to be any requirements of the ancestor's class name. The external container will need to define the widget theme variables, though.

[coveralls]

coverage: 91.089% (+0.003%) from 91.086%
when pulling 3e2d35d on x/widget-container
into 0c01a20 on master.

[ibgreen]

Considering API options:

• Seems to me that root could also be a valid placement, which would then ignore viewId?

[chrisgervang]

Placement doesn't have any interactions with viewId in implementation, it just positions within a view (or root) box. Perhaps the name is a little confusing.. "alignment" would have been a great name since that values are like "top-left", except that "fill" is an option.

If we're open to a breaking change, "alignment" could be more clear to new users

[ibgreen]

Is the goal to make widgets usable outside the deck.gl canvas?

While useful, are there "scope creep" risk with this? There was a lot of concern about this early on, we did not set out to build a generic UI system and make ourselves a target for a "never ending list of corner-cases".

[chrisgervang]

Valid point.. I think this external container idea aligns with early widget visions that included making sidebar panels.

Still, the unknown implications are my main concern as well. I'd be open to marking container as an experimental API to see how it works in practice before locking it in. Wdyt?

It'd be great to see basic examples in purejs and react to validate this concept is a good idea

[chrisgervang]

#8057 - while CARTO isn't actively pushing this use case, I can see others (and myself) having the use case. In a sense, a widget is an accessor of deck's state and update lifecycle

[ibgreen]

Yes, agree it is extremely useful. However, there is likely a "long tail" when starting to integrate into an external DOM.s

• I feel we have an opportunity to be deliberate about this (i.e. update the Widget roadmap / vision / deck and also our documentation) to set some expectations / goals for this.
• Generally, we made a lot of progress on widgets in 2025 and I think an updated "Widgets 2026 roadmap" would be great. We still have the widgets working group channel etc in place.

But as you say, if time does not permit, we can of course always slap it in as an experimental _container prop just to get it in place for now.