allotment, and the split pane behaviour VS Code already solved

Derived from the same codebase as VS Code's split view

Allotment is a React split-pane component, and the origin is stated without false modesty: if you like the look and feel of VS Code's split view implementation, this component is derived from the same codebase.

That single fact explains most of the library. A split pane is one of those interfaces that is easy to approximate and hard to get right. The drag behaviour, the splitter hit area, the way a pane collapses when you drag past its limit, the pixel rounding that stops the layout from drifting, and the keyboard and accessibility details are all things that VS Code, which is used all day by a large population of developers, has already tuned over years. Starting from that implementation is a shortcut past a lot of fiddly work.

The feature list reads as a direct consequence. It is React based, so it integrates into an existing React application. It is dynamic, meaning you can declaratively add and remove panes. It is flexible: snap panes closed, nest split views, show and hide panes, and persist sizes across reloads. It is typed, written in TypeScript with type definitions included.

The audience is React developers building a dashboard, an IDE-like tool, a log viewer or a settings panel with a resizable sidebar, and the differentiating question is not whether you can build a two-pane split by hand, because you can, but whether you want to rebuild the drag physics and the snapping rules of a mature editor for every project.

The package is MIT licensed, the documentation site lives on a project subdomain, and the repository keeps a changelog, a code of conduct, a security policy and an AGENTS.md.

Install, render two panes, and give the parent a height

The quick start is short enough to paste into a project.

npm install allotment

Allotment requires React 17, 18 or 19, and react and react-dom are peer dependencies, which is the right arrangement for a component library that renders with whatever React the application already has.

The first render is two panes and a stylesheet import.

import { Allotment } from "allotment";
import "allotment/dist/style.css";

export const App = () => (
  <div style={{ height: 400 }}>
    <Allotment>
      <div>Pane A</div>
      <div>Pane B</div>
    </Allotment>
  </div>
);

The detail that catches everyone out is in the next line of the documentation. Allotment fills its parent element, so make sure the parent has a height. The documentation routes you to a specific FAQ entry if nothing is showing.

That is the right design, and it is also the most common support question for a component like this. A split pane that sizes itself from its content cannot work, because the content of a pane is what the user is resizing, and a component that sizes to its parent needs the parent to have a definite size. A component that measured itself would either collapse to zero or fight the user while dragging.

The stylesheet import is the other thing worth noticing. The component ships a CSS file under dist, which means the package is not styled by a CSS-in-JS runtime and does not need one, and the application is responsible for including that one file.

Layout, sizing, snapping, nesting, closable panes, visibility, reset

The documentation is organised by the feature areas, and the list is a good map of what the component can do.

Layout covers the basic structure, and sizing covers the pane sizes themselves, including how a pane can be given a minimum or maximum. Snapping covers the behaviour where a pane is dragged closed, which is the part that makes a split view feel right, since the pane has to end in a defined state rather than at an arbitrary fraction of the container. Nesting covers split views inside split views, and adding and removing panes covers the closable case, where a pane can be closed and reopened. Visibility covers showing and hiding a pane without destroying its content. Reset and resize covers returning the layout to a known state.

Each of those pages has live examples, which is the documentation style that suits this kind of component, because the only way to judge a splitter is to drag it.

Two of them are worth singling out for anyone evaluating the component. Closable panes and visibility are the two that interact badly with state, because a pane that is closed and reopened has to keep its contents and its size, and that is where a naive implementation loses data or resets the layout. And the reset behaviour matters for a pane whose size is persisted, because the stored size has to be reconciled with a new container size rather than blindly restored.

The API reference is split across three pages, the overview, the Allotment component and the Allotment.Pane component, which tells you the public surface is small enough to read in full.

Persisting sizes, styling and server rendering

Three how-to guides cover the things that come up once a split pane is in a real application.

Persisting sizes is the one most projects need. The requirement is stated in the feature list as the ability to persist sizes across reloads, and the guide covers how to do it, which means writing the pane sizes somewhere and restoring them on mount. The interesting part of that problem is not the storage, it is the reconciliation: a stored size is a fraction or a pixel count from a window of a particular size, and on a different screen the same number means something different. A layout that restores literally is wrong on any machine but the one that saved it.

Styling covers the CSS. Since the component ships a stylesheet, the question is how to override it, and the guide is where the recommended approach is documented, including the class names to target and how the splitter itself is drawn.

Server rendering and Next.js is the third. This is the case where a component that measures the DOM during mount can break, because on the server there is no DOM, and because a client component that renders differently on the server and the client produces a hydration mismatch. The existence of a dedicated guide is a signal that the author has thought about it rather than discovered it in bug reports.

There is also an FAQ page, which is where the questions that do not fit a feature page end up, including the one about the parent element not having a height.

The alternative, and how the two differ

The project names its alternative, and it is worth reading that section carefully because the difference is stated in terms of behaviour rather than features.

Allotment aims to reproduce the behaviour of VS Code's split view. If you need something different, react-resizable-panels is a popular alternative.

That is the whole comparison, and it is a real one. The two libraries take different approaches to the same problem, and the difference is not in the API surface but in the model underneath. Allotment's model is the editor's: a drag on the splitter, a set of constraints, and a pane that either snaps shut or refuses to go below its minimum. react-resizable-panels is offered for the cases where you need something different, and choosing it is choosing a different feel for the drag.

For a dashboard with a sidebar and a main panel, either will do, and the deciding factor is often familiarity, since a user who has used VS Code expects the editor behaviour. For a layout with unusual constraints, or one where you want the resizing model to differ from the editor's, the project is telling you to look elsewhere.

What Allotment does not claim is that it is a general purpose layout system. It is a split pane, and it is opinionated about what a split pane does.

Three published builds, one stylesheet, six dependencies

The package manifest shows a modern dual build rather than a single bundle. The exports map has a require condition pointing at dist/legacy.js, an import condition pointing at dist/modern.mjs, and types pointing at dist/types/src/index.d.ts, with the main field at the legacy build and the module field at dist/module.js.

That is the shape you want in 2026 for a library consumed by both bundler and node resolution, and it is what lets an application get modern syntax through the import condition and a CommonJS consumer get the legacy bundle without the package shipping two copies of everything.

The files list publishes the mjs builds, the js builds, the css and the type declarations, and nothing else, so the source, the tests and the storybook stories stay out of the published tarball.

The runtime dependencies are six, and they are all small and well chosen. classnames for conditional class names, eventemitter3 for the event emitter, fast-deep-equal for comparing pane and layout state, lodash.clamp and lodash.debounce for the constraint arithmetic and the drag throttling, and usehooks-ts for the React hooks the component needs. There is no styling runtime, no state library and no date or utility mega-package, which is a deliberate signal about the library's scope.

The build itself uses rollup with the Babel, commonjs, node-resolve and terser plugins, and there is a babel.config.js, a jest.config.ts for tests, a .browserlistrc for browser targets, a .prettierrc.json for formatting, an eslint configuration, a husky directory for git hooks, a lint-staged configuration, and a renovate.json for dependency updates. There is a stories directory and a .storybook directory, which is how the live examples in the documentation are built.

Editorial conclusion

Adopt allotment if you need split panes in a React application and want the behaviour users already know from VS Code, including the snapping and the drag semantics, rather than inventing your own resizer. Do not adopt it if your layout needs something the component deliberately does not do, since the project points at react-resizable-panels for that case, and do not expect a zero-dependency package, since it pulls in classnames, eventemitter3, fast-deep-equal, two lodash helpers and usehooks-ts. Before you start, give the parent element a height, because allotment fills its parent and the documentation routes you to the FAQ when nothing shows.

Frequently asked questions

Official sources

1. johnwalley/allotment on GitHub
2. License: MIT
3. Project website
4. README
5. Releases