dockview-react

dockview-react is the official React package for Dockview, a framework-agnostic docking layout engine that recreates the panel/tab/grid experience found in IDEs like VS Code. It wraps the underlying dockview core API in a DockviewReact component (plus dedicated Gridview, Splitview, and Paneview components) so panel content, tab headers, watermarks, and context menus can all be authored as ordinary React function components, while the actual layout math and drag-and-drop mechanics stay in the framework-agnostic core.

Under the hood it uses a portal-based bridge (ReactPart / ReactComponentBridge in react.ts) to mount user components into DOM nodes that Dockview’s vanilla-JS core creates and owns, forwarding imperative prop updates without React ever taking control of that DOM subtree. The package tracks the peer dockview runtime version, ships full TypeScript types for every extension point, a jsdom-tested suite, and stylesheet exports for theming.

What You Get

• DockviewReact component - a forwardRef React component wrapping the core createDockview API, exposing an imperative DockviewApi via onReady.
• Gridview, Splitview, and Paneview React components - dedicated bindings for Dockview’s other layout primitives alongside the tabbed docking view.
• Portal-based rendering bridge - a ReactPart/usePortalsLifecycle implementation that mounts arbitrary React components as panel content, tab headers, watermarks, and context-menu items inside the vanilla-JS layout DOM.
• Full theming and styling hooks - ships a dockview.css stylesheet plus prebuilt themes (e.g. themeDark) importable alongside the components.
• TypeScript types for every extension point - typed props for tab components, header actions, context-menu items, drag-ghost renderers, and watermark panels.

Common Use Cases

• Building IDE-like editor layouts (VS Code-style tabs and panels) inside a React app, such as internal dev tools or code playgrounds.
• Trading and monitoring dashboards (“workbench” UIs) with multiple resizable, dockable, and poppable panels showing live data.
• Admin panels and BI tools where users rearrange, float, or pop out panels into separate browser windows.
• Multi-pane authoring tools (design or CMS editors) that need draggable tab groups and split views without hand-rolling drag-and-drop.

Under The Hood

Architecture dockview-react wraps the vanilla-JS dockview core API in a set of React.forwardRef components (DockviewReact, plus Gridview/Splitview/Paneview counterparts) organized one-per-layout-primitive under src/{dockview,gridview,splitview,paneview}/. The central abstraction is the portal bridge in src/react.ts: ReactPart implements the core package’s IFrameworkPart interface and uses ReactDOM.createPortal plus a monotonic-counter-driven force-render to imperatively push prop updates into React-rendered content that lives inside a DOM subtree owned and mutated by the vanilla-JS layout engine. DockviewReact itself synchronizes its many optional props (tab components, header actions, watermark, context menus, drag-ghost renderer) into the core’s updateOptions calls via a battery of targeted useEffect hooks keyed on individual prop groups, keyed against a shared PROPERTY_KEYS_DOCKVIEW list from the core package. If that core contract or the IFrameworkPart interface changes, this bridge is the first thing that breaks.

Tech Stack Written in TypeScript with peer dependencies on react and react-dom (versions 16.8 through 19) and a single runtime dependency on the sibling dockview package (itself a re-export of dockview-core). Builds run through tsc for declaration-only type output and rolldown for the CJS/ESM/UMD bundles, orchestrated across the monorepo with Nx and Yarn workspaces. Tests run under Jest with @swc/jest and a jsdom environment, with moduleNameMapper resolving sibling packages from source rather than built output. CI spans GitHub Actions workflows for build/test, npm publishing with provenance, releases, and CodeQL security scanning, with coverage tracked on SonarCloud.

Code Quality Twelve spec files cover the dockview, gridview, splitview, and paneview components individually plus a dedicated top-level suite exercising the portal bridge itself and a regression spec guarding against an enterprise-license warning leaking onto mount — evidence of deliberate regression-test discipline across package boundaries in the monorepo. Linting and formatting run through Biome, and an attw (are-the-types-wrong) check is wired into the scripts to catch type-resolution mismatches across module formats before publish. Error handling favors loud, explicit exceptions (e.g. rejecting non-React components or double-disposal of a resource) over silent failure.

What Makes It Unique The package’s real contribution isn’t the docking/layout algorithm itself — that lives in the framework-agnostic core — but the portal-based bridge that lets arbitrary React components be rendered as panel content, tabs, headers, and context-menu items inside a DOM subtree that a purely imperative, vanilla-JS engine creates and controls, without React ever owning that subtree. That’s a materially different design than most “React wrapper” packages, which typically reimplement the whole layout in React. Developer experience centers on a single DockviewReact component with an imperative onReady handoff to a DockviewApi, plus a wide but optional set of named component props for customizing every renderable extension point.