Image Reorder Grid — Drag-and-Drop Photo Order

Every product, gallery, or media-management UI eventually needs the same control: a grid of images a user can physically drag into a new order, with the first slot understood as "the cover" or "the primary" image. This snippet builds that exact pattern using the browser's native HTML5 Drag and Drop API — no external sorting library — with a live-updating cover badge and order numbers.

Native drag-and-drop, not a library

Every tile is a real draggable="true" element wired to the five native drag events: dragstart (marks the dragged item and records its index), dragover (calls preventDefault(), which is required for drop to fire at all, and highlights the hovered target), dragleave (clears that highlight), and drop (performs the actual reorder). This is the same API every framework-agnostic drag library wraps under the hood — using it directly here keeps the snippet dependency-free and easy to port.

The reorder itself is two array operations

On drop, PHOTOS.splice(dragIndex, 1)[0] removes the dragged photo from its old position and returns it, and PHOTOS.splice(dropIndex, 0, moved) reinserts it at the new position — the standard "remove then insert" pattern for moving an item within an array. The whole grid then re-renders from the mutated array, so the DOM never needs to be manually shuffled; it simply reflects whatever order PHOTOS is currently in.

The cover photo is a position, not a flag

Rather than storing a separate isCover: true/false field that could drift out of sync with the actual order, "being the cover" is derived purely from array position: whichever photo is at index 0 gets the .cover class, the amber ring, and the "Cover" tag, recomputed fresh on every render. Drag any other photo into the first slot and it instantly *becomes* the cover — there's no separate "set as cover" action to remember to use.

Visual feedback during the drag

The dragged tile fades to 35% opacity and shrinks slightly via .dragging, so it's visually clear which tile is in motion without it disappearing entirely (which would make it hard to track), and the tile currently being hovered over gets an inset indigo ring via .drag-over, showing exactly where the drop will land before the user releases.

Why drag-and-drop beats numbered inputs

An older pattern for photo ordering asks users to type a position number into each thumbnail — technically equivalent, but it asks people to do arithmetic about their own intent ("this should be 3rd, so the others shift down") instead of just performing the action they're thinking of. Dragging a tile to where it visually belongs maps directly to the mental model, which is why every modern photo-managing interface has converged on it over manual position fields.