Reorder
Drag-to-reorder is the one interaction where the naive implementation is always wrong: re-render the list on every pointer move and you drop frames, lose focus and reset component state. BmotionReorderGroup previews the new order with transforms only - the list itself re-renders once, on release - so the drag stays smooth and the bound list is the single source of truth throughout.
Drag to reorder
Bind a list, give the items a stable key, and every row becomes draggable along the list
axis while its siblings spring out of the way. HandleSelector restricts the
gesture to a grip inside each row so the rest of it stays clickable and selectable, and
OnReorder fires once the new order has been committed.
Current order: One More Time → Digital Love → Harder Better Faster → Something About Us → Voyager
Committed reorders: 0
Horizontal lists
Axis="BmDragAxis.X" runs the same machinery sideways for a row of tabs, a
toolbar or a card rail. Only the axis changes - the displacement, the commit and the binding
all behave identically. Wrapping grids are not supported: the group needs a single line to
reason about order along.
Current order: Draft → Review → Approved → Shipped
Keyboard access
A pointer drag is not reachable by keyboard, so a reorderable list needs a second way in -
and it does not need to be a separate mechanism. The group observes external mutations of
the bound list, so plain move-up / move-down buttons that reorder Items
directly (the ▲▼ controls in the first sample) animate exactly like a drag would. The same
applies to any other source of order: a sort, a server push, an undo.