The tab overflow UI has two pieces of chrome that are currently hardcoded. Custom tab renderers already receive TabLocation = 'header' | 'headerOverflow' so the per-tab content inside the popover is customizable, but the surrounding chrome is not.
1. Overflow dropdown trigger
The chevron+count button shown in the right tab actions when tabs overflow is built by createDropdownElementHandle() in tabOverflowControl.ts and called directly at tabsContainer.ts:412. There is no option, framework binding, or public type to override it.
Proposed shape, mirroring the existing component-option pattern:
interface DockviewComponentOptions {
createOverflowDropdownComponent?: (params: {
tabs: number;
}) => DropdownElement;
}
with DropdownElement (the { element, update, dispose? } shape) exported from the public API.
2. Overflow popover content
When the trigger is clicked, the popover body — scroll wrapper, group headers (color dot + label + collapsed-count badge), tab wrappers — is built imperatively in tabsContainer.ts:434-555 with no extension point. Users can re-skin individual tab entries via the existing tabComponent mechanism (because createTabRenderer('headerOverflow') is invoked per-tab), but the container and group headers cannot be replaced.
Options here, in order of increasing flexibility:
- Expose a renderer for just the group-header row.
- Expose a full popover-content renderer that receives the list of overflowed tabs/groups and returns the element, with the per-tab renderer still available as a building block.
Why bundle these
Both gaps live in the same overflow flow and would be addressed by the same kind of "renderer option on DockviewComponentOptions + public type export" pattern that already exists for watermark, tabs, etc. Doing them together keeps the API surface coherent.
The tab overflow UI has two pieces of chrome that are currently hardcoded. Custom tab renderers already receive
TabLocation = 'header' | 'headerOverflow'so the per-tab content inside the popover is customizable, but the surrounding chrome is not.1. Overflow dropdown trigger
The chevron+count button shown in the right tab actions when tabs overflow is built by
createDropdownElementHandle()intabOverflowControl.tsand called directly attabsContainer.ts:412. There is no option, framework binding, or public type to override it.Proposed shape, mirroring the existing component-option pattern:
with
DropdownElement(the{ element, update, dispose? }shape) exported from the public API.2. Overflow popover content
When the trigger is clicked, the popover body — scroll wrapper, group headers (color dot + label + collapsed-count badge), tab wrappers — is built imperatively in
tabsContainer.ts:434-555with no extension point. Users can re-skin individual tab entries via the existingtabComponentmechanism (becausecreateTabRenderer('headerOverflow')is invoked per-tab), but the container and group headers cannot be replaced.Options here, in order of increasing flexibility:
Why bundle these
Both gaps live in the same overflow flow and would be addressed by the same kind of "renderer option on
DockviewComponentOptions+ public type export" pattern that already exists for watermark, tabs, etc. Doing them together keeps the API surface coherent.