dnd-kit: a layered drag and drop toolkit for React, Vue, Svelte and Solid

The problem dnd-kit solves, and who it is built for

HTML5 drag and drop events are awkward for anything beyond moving a file onto a drop zone. Reordering a list, dragging between two containers, or making the same interaction work with a keyboard means writing pointer tracking, collision detection and focus management yourself. dnd-kit exists to supply that layer. The README describes it as "a modern, lightweight, performant, accessible and extensible drag and drop toolkit for the web", and the feature list names the use cases it targets: lists, grids, multiple containers, nested contexts, variable sized items, virtualized lists and 2D games.

The audience is front-end engineers building interactive interfaces rather than simple file uploads. The repository ships adapters for React, Vue, Svelte and Solid, plus a vanilla JavaScript path, so the same core is meant to serve teams on different frameworks. If your drag interaction is a single draggable element dropped on a single target, the toolkit is heavier than the problem. If you are maintaining a sortable table, a kanban board or a nested tree, the built-in sortable layer and the multi-container support are the reason to look here.

How the layered architecture actually fits together

The README is explicit that the architecture is built in layers. At the bottom sits @dnd-kit/abstract, described in the package table as the abstract core. Above it, @dnd-kit/dom is the framework-agnostic DOM layer. The framework packages (@dnd-kit/react, @dnd-kit/vue, @dnd-kit/svelte, @dnd-kit/solid) are thin adapters over that DOM layer. Two supporting packages sit alongside: @dnd-kit/collision for collision detection and @dnd-kit/geometry for geometry utilities, with @dnd-kit/state handling reactive state management and @dnd-kit/helpers holding helper functions.

That split has a practical consequence. Collision detection is not buried inside the React adapter, so a custom algorithm is a matter of working against @dnd-kit/collision rather than patching a framework component. The README also states that you can build your own sensors, customize key bindings, and adjust animations, transitions, behaviours and styles. Input handling is layered the same way: pointer, mouse, touch and keyboard sensors are listed as built-in, and accessibility support (keyboard handling, default ARIA attributes, screen reader instructions and live regions) is described as built-in rather than opt-in.

The cost of this design is that a newcomer has to decide which layer to import from. The README does not walk through that decision; it links to per-framework quickstarts on dndkit.com and lists the packages in a table. Expect to read the quickstart page for your framework before you write the first draggable.

Installing dnd-kit and getting a first draggable onto the page

The README does not print install commands for the framework packages. It says to choose a framework and links to quickstart pages, so the package names below come from the package table in the README. For React, the relevant entries are @dnd-kit/react for the adapter and @dnd-kit/dom for the DOM layer beneath it. Install both with your package manager of choice:

npm install @dnd-kit/react @dnd-kit/dom

The README's package table is the source for these names, and the quickstart page for React is where the component and hook usage is documented. Treat dndkit.com/react/quickstart as the authority for the exact imports, because the README itself only links there.

If you want the sortable behaviour rather than raw drag and drop, the README points at a subpath instead of a separate package: "Need to build a sortable interface? Check out @dnd-kit/dom/sortable, a thin layer built on top of the core." That is an import path, not an npm package, so you still install @dnd-kit/dom and import from the sortable entry point.

Contributors work differently. The repository is a monorepo managed with Turborepo and bun, and the README gives the contributor commands directly:

bun install
bun run build
bun run dev

The root package.json confirms the tooling: turbo is a devDependency, packageManager is [email protected], and the workspaces array covers packages/* and apps/*. The dev script runs turbo run dev with a concurrency of 20, which tells you the monorepo expects many packages running at once.

Where dnd-kit stops being the right tool

The README's feature list is broad, but the documentation it points to is external. Anything not described in the README, including migration between package versions and the full sensor API, lives on dndkit.com. If your team cannot depend on an external documentation site, that is a real constraint, because the repository README will not carry you through a non-trivial implementation.

The version numbers in the recent releases are worth reading carefully. The Vue, Svelte and state packages were published at 0.5.0 on 2026-06-11. Pre-1.0 versioning on the framework adapters means the API surface can still move, and the root package is named dnd-kit-experimental, which is consistent with that. The React package is the one the search data asks about most, but the README does not claim any adapter is more stable than another. If you need a frozen API with a long support window, verify the current version of the specific adapter you plan to use before committing.

There is also a scope limit worth naming. The toolkit handles drag and drop interactions. It does not persist order, sync across clients, or resolve conflicts when two users reorder the same list. Those are application concerns, and nothing in the README suggests otherwise. Teams often arrive expecting the sortable layer to own the data model. It does not.

dnd-kit against react-dnd, and what changes in practice

The most common comparison in the search data is dnd-kit versus React DnD, and the two take different routes to the same problem. React DnD models drag and drop around a backend abstraction: it separates the drag sources and drop targets you declare from the HTML5 or touch backend that carries the interaction. dnd-kit instead splits by layer, with @dnd-kit/abstract as the core, @dnd-kit/dom as the DOM implementation, and framework packages as thin adapters on top. The README's phrase for this is that the architecture is built in layers.

The practical difference shows up in two places. First, dnd-kit ships adapters for React, Vue, Svelte and Solid from one core, so a team with mixed front ends is not choosing a React-only library. Second, collision detection is its own package, @dnd-kit/collision, which makes swapping the algorithm a first-class operation rather than a backend configuration. React DnD's backend model is a different shape of customization, aimed at the input and environment rather than at the collision math.

Neither approach is free. dnd-kit's layering means more packages in your dependency list and more decisions about what to import. React DnD's backend model means learning its connector and monitor concepts. The README for dnd-kit does not argue the comparison, so the honest answer is that the choice depends on which abstraction your team finds easier to reason about, not on a benchmark.

Maintenance, releases and what the MIT licence means here

The repository is not archived, and the last push was on 2026-09-12, so the project is being worked on. Releases are managed with changesets: the root package.json defines a changeset script, version-packages, release, and beta variants (version-packages:beta and release:beta). That tells you the maintainers publish through an automated versioning flow rather than tagging by hand, and it means upgrade notes arrive as changeset-generated changelogs. The @changesets/changelog-github dependency confirms the changelog source is GitHub.

Upgrade cost is tied to the pre-1.0 versions. The Vue, Svelte and state packages moved to 0.5.0 on 2026-06-11, and the root package is named dnd-kit-experimental. Minor version bumps in a 0.x line can carry breaking changes, so pin your adapter version and read the changeset entry before moving. Because the adapters are thin layers over @dnd-kit/dom, a breaking change in the DOM layer can surface in every framework package at once. Check the versions of both the adapter and the DOM layer when you upgrade.

The licence is MIT, stated in the README and present as a LICENSE file at the repository root. MIT permits commercial and closed-source use with attribution and without a copyleft obligation on your own code. This is a description of the licence text, not legal advice; if your organisation has a policy on third-party dependencies, route it through the people who own that policy.

Editorial conclusion

Adopt dnd-kit when you need a sortable list or a multi-container drag interface and you are willing to learn the layered package structure, because the README points you at @dnd-kit/dom and @dnd-kit/react rather than a single entry point. Do not adopt it if you want one import that hides the layers, or if you need a drag behaviour the collision and sensor packages do not expose. Before writing code, open the quickstart for your framework on dndkit.com and confirm which packages that page tells you to install, since the README itself only links out.

Frequently asked questions

Official sources

1. clauderic/dnd-kit on GitHub
2. License: MIT
3. Project website
4. README
5. Releases