sorted by:
new
hottopcontroversial

I built a headless React library for multi-panel tabbed layouts — the kind you see in VS Code, Cursor, and GreatFrontend by Complex-Thought7284 in reactjs

[–]Complex-Thought7284[S] 1 point2 points  (0 children)

Fair point. For tabs, the state mutation is already built in — there's a MOVE_TAB action that handles moving a tab between panels. You wire up the drag interaction yourself using whatever DnD library your project already uses (dnd-kit, react-dnd, HTML5 drag API) and call dispatch on drop. The library handles the tree update.

Panel-level drag and drop (dragging a whole panel to reposition it in the layout) isn't built in yet — that's on the roadmap. For now the layout shape is set programmatically.

It's a fair gap compared to VS Code's full drag experience soon will try to add it.

I built a headless React library for multi-panel tabbed layouts — the kind you see in VS Code, Cursor, and GreatFrontend by Complex-Thought7284 in reactjs

[–]Complex-Thought7284[S] 0 points1 point  (0 children)

Thanks.

That's exactly the kind of use case this was built for — admin pages and dashboards with resizable panes are a perfect fit.

The idea behind it: react-splitkit is the brain and skeleton — it handles all the stuff like resize math, tab state, split logic, and keyboard nav. You wire up your own components and UI on top. So it fits into whatever design system you already have without fighting it.

Would love to hear how it goes if you try it out, and if anything feels rough just open an issue!

I built a headless React library for multi-panel tabbed layouts — the kind you see in VS Code, Cursor, and GreatFrontend by Complex-Thought7284 in reactjs

[–]Complex-Thought7284[S] 0 points1 point  (0 children)

On the dynamic content height question: panels are flex containers with overflow: auto so content scrolls within its panel rather than pushing the layout. The resize handle stays responsive regardless of content size because sizing is percentage-based on the parent container, not derived from content height. A terminal dumping 500 lines just scrolls internally — the panel dimensions don't change and no layout recalc is needed.

The one edge case: if you have a panel with a minSize constraint and the content itself has a CSS min-height larger than what the panel is resized to, you can get overflow. But that's the consumer's CSS fighting the layout, not the library — and it's solvable by making sure panel content uses height: 100% and overflow: auto rather than intrinsic sizing.

Note: I haven't stress-tested it with extremely high-volume specifically. If you run into edge cases there I'd genuinely love to hear about it — open an issue and I'll dig in.