Drag and drop is the interaction with the widest gap between "works in the demo" and "works for everyone". The demo needs a mouse, one list and a stable layout. The real thing needs a keyboard path, a touch path that does not fight the page scroll, an announcement for every move, and a server that might reject the change after the card has already moved.
10 public components on 21st have "kanban" in the name and 19 more say "drag". Below is what each shape is for, and the four things that decide whether it is usable.
The board
Kanban by Hayden Bleasel is the plain, well-described version. Trello Kanban Board by Kousthubha Yadiyala is the familiar full take, Kanban by Hover.Dev is the interactive one, Kanban by sean0205 is built for item organisation, and Kanban by Shailendra Kumar shows a task count per stage.
That last detail is the one worth copying: a column header carrying a count turns a board from a picture into a readout, and it is the first thing anyone actually reads.
The sortable list
Reordering within one list, which is most of what people need when they think they need a board. Draggable Priority List by nikhiljainsam is the shape to look at, because its author built the keyboard path in as well as the pointer one, with rank numbers alongside.
If the reordering is the point and there are no columns, do not build a board. A list is a fifth of the work and has none of the cross-container edge cases.
Free arrangement
Draggable Card by Manu Arora, Drag cards by Le Thanh and Swapy Draggable Card by UI Layouts are the layout-shuffling family, where position is decoration rather than data. Infinite Drag + Scroll Gallery by rylenlobo is the draggable canvas version.
These are the fun ones and the least demanding, because nothing is being recorded: if a card lands somewhere odd, nothing broke.
The four things that decide whether it works
A keyboard path, or it is not finished. The accepted pattern: the card is focusable, Space or Enter picks it up, arrows move it, Space drops it and Escape cancels. Without that, reordering is available only to people using a pointer, and a board is usually a work tool where that is not acceptable. This is the strongest reason to take a library rather than write it.
Announcements at every stage. Picked up, moved to position 3 of 7 in Review, dropped, cancelled. A live region carrying those sentences is the difference between a usable keyboard path and a silent one.
Touch that does not fight scrolling. On a phone, a drag gesture and a scroll gesture are the same movement. The usual answer is a long press to start the drag, plus touch-action: none on the handle only, never on the whole board, or the reader can no longer scroll the page. Auto-scroll when a card is dragged near the edge is not a polish item on mobile, it is what makes a board with more than one screen of cards usable at all.
Optimism with a rollback. The card must move on drop, before the request. Which means the failure path has to exist: put it back, and say why. A board that silently keeps a card in a column the server rejected is worse than one that felt slow.
The state, which is where the bugs live
Two decisions that save a rewrite.
Store an order value, not an array index. Reordering by index means rewriting every row after the moved one, and two people dragging at once produce nonsense. A fractional rank between the neighbours - or a proper lexicographic ordering key - means one row changes per move.
And decide what a column is. If the column is a status field on the card, moving between columns is a field update and the board is a view. If the column owns its own ordered list, you are maintaining two sources of truth about where a card lives, and they will disagree.
Where else to look
The honest list of alternatives, because the answer is not always us:
| Source | Best for | Trade-off |
|---|---|---|
| dnd-kit | The current default: keyboard support, sensors, sortable presets | You assemble the board yourself |
| Pragmatic drag and drop | Large boards, built on the native HTML drag API, framework-agnostic | A lower-level API |
| Native HTML drag and drop | The simplest cases, no dependency | No touch support and almost no styling control |
| 21st | Finished boards, sortable lists and draggable canvases | Quality varies by author, so preview before you take it |
Taking one
Every component page has a live preview and the code. Installing goes through the shadcn CLI against our registry:
That key comes from your 21st account, and installs require a membership. Set API_KEY_21ST once in your shell and the command works for anything in the catalogue. The 21st MCP covers the same ground without leaving the editor: ask Claude, Cursor or Codex for a kanban board, get the previews inline, and let the agent write the file.
Frequently asked
- How do you make drag and drop keyboard accessible?
- Make the card focusable, let Space or Enter pick it up, arrows move it, Space drop it and Escape cancel. Pair every stage with a live-region announcement: picked up, moved to position 3 of 7 in Review, dropped, cancelled. This is the strongest reason to take a library rather than write the interaction yourself.
- Why does dragging break scrolling on mobile?
- Because a drag and a scroll are the same gesture. Start the drag on a long press, apply touch-action: none to the handle only and never to the whole board, and add auto-scroll when a card nears the edge. Without auto-scroll, a board taller than one screen cannot be used on a phone at all.
- Should a card move before the server confirms?
- Yes, but only if the rollback exists. Move it on drop so the interaction feels immediate, then put it back with an explanation if the request fails. A board that silently keeps a card in a column the server rejected is worse than one that felt slow.
- How should card order be stored?
- As an order value on the row, not an array index. Index-based ordering rewrites every row after the moved one and produces nonsense when two people drag at once. A fractional rank between the neighbours, or a lexicographic ordering key, changes one row per move.