Row reordering (drag-and-drop / programmatic)

[jbetancur]

Summary

Add the ability to reorder rows, both interactively (drag-and-drop) and programmatically, mirroring the existing column reordering capability.

Motivation

The library already supports column reordering. Row reordering is a common companion requirement: manual priority ordering, building ordered lists/queues, arranging steps, etc. There is currently no first-class way to do it.

Proposed API (for discussion)

• draggableRows?: boolean — enable drag-to-reorder on rows.
• onRowOrderChange?: (nextData, { from, to, row }) => void — fired after a reorder; consumer owns the data array and updates state.
• Optional drag handle column / handle affordance rather than whole-row drag, to avoid conflicts with row click / selection.

Considerations

• Interaction with selectableRows, expandable rows, and row click handlers (drag vs. click disambiguation).
• Interaction with sorting: reordering only makes sense against an unsorted / manual order; decide whether enabling drag disables sort or reorders the underlying array.
• Pagination: whether drag can move a row across pages.
• Accessibility: keyboard-based reordering (move up/down), ARIA grabbed/dropeffect semantics.
• RTL support (consistent with recent column reorder RTL fix).
• Compose with column pinning and the planned native row pinning (Native sticky-on-scroll row pinning (pinnedRows / pinnedRowIds) #1340).

[jbetancur]

Extension idea: drop targets (drag row to trash / archive / assign)

Building on this, once rows are draggable we get drop targets almost for free — drag a row out to a trash bin (Gmail-style), an archive zone, an "assign to" bucket, etc. Reorder and "drop on a target" are the same gesture with different destinations.

Why it composes cleanly: the library already uses native HTML5 DnD for column reordering (draggable + dataTransfer + setDragGhost). Row DnD would put the row's identity on the drag event; a drop target is just another drop zone that reads it.

Proposed shape (consumer-owned target):

• The consumer renders the drop zone in their own JSX (outside <DataTable>) and attaches onDragOver/onDrop.
• The library exposes what's being dragged (row + id) so the target can react, and fires a callback like onRowDrop / onRowRemove with the dropped row.
• The consumer mutates their own data on drop — the library never deletes; it reports the event.

Works in every mode: because the drop target is the consumer's JSX and the mutation happens in consumer state, this is immune to the controlled/uncontrolled question — data is already a consumer-owned prop, so there's no internal-state fork to worry about. The alternative (a built-in bin the library renders inside the table) would force the library to own drag-visibility state; the external-target design avoids that and is simpler.

Caveats:

• Depends on row reordering landing first — this is a drop-target extension of it, not a standalone feature.
• Accessibility needs a keyboard equivalent (a delete/move action), same as the keyboard-reorder concern above.
• The Gmail feel (bin fades in only during drag, row animates out, undo toast) is mostly consumer-side polish; the library provides the mechanism, the app builds the delight.

[jbetancur]

Tracked as a separate follow-up: #1373 (row drop targets), blocked by this issue. This issue covers row reordering itself; #1373 extends the drag machinery to consumer-defined drop zones (eg think gmail trash / archive / assign).