Dashboard Widget Grid — Drag & Drop HTML CSS JS

Both are API-order quirks. When a drag starts, the browser synchronously snapshots the element to use as the ghost image that follows the cursor — and it takes that snapshot after your dragstart handler runs. Apply opacity: 0.35 synchronously and the ghost itself is captured dimmed and dashed, which looks broken; deferring the class one frame with requestAnimationFrame lets the browser capture the pristine widget while the in-grid original still dims immediately after. setData exists because Firefox implements the spec strictly: a drag with an empty data store is considered vacuous and never starts (Chrome is lenient). Setting any payload — the widget id is the natural choice — makes the drag universal, and the id payload is also what you would read in a cross-container drop (dragging a widget from a catalogue panel into the grid).

Because in a grid with mixed spans, only the real layout engine can tell the truth. An insertion line says "it will go between these two" — but with a 2-column grid containing span-2 widgets, inserting one card can re-wrap every subsequent row, and a line cannot communicate that cascade; users drop, the layout jumps to something the line never showed, and the interaction feels lying. Moving the dragged node live makes CSS Grid itself render the preview: what you see mid-drag is by construction identical to the drop result, wide-widget cascades included. The costs are real but small: DOM mutation on every dragover crossing (throttled naturally by the over-a-new-widget check), and the node moving means dragend must not assume original position — which this code never does. The alternative placeholder approach earns its complexity only when the dragged item must stay visually in place while a ghost travels, as in cross-window drags.

By storing intent, not geometry, and restoring defensively. The saved layout is just an ordered list of widget ids with a wide flag — no coordinates, no indexes into anything. restore() walks that list and, for each id, moves the matching live widget into position via appendChild (which relocates rather than clones) — and simply skips ids with no matching element, so a widget you removed in v2 disappears from saved layouts harmlessly instead of corrupting them. New widgets added since the save were never in the list, so they are never moved: they retain their DOM order and end up after the restored ones — a sensible "new things appear at the end" default. The one upgrade worth adding for server-side persistence is a schema version field alongside the array, so a future layout format (say, adding a tall flag or multi-column coordinates) can migrate old payloads explicitly rather than by inference.

In React, do not port the DOM-moving approach literally — React owns the DOM, and nodes you relocate behind its back get clobbered on the next render. Instead, invert it: hold layout as state ([{ id, wide }]), render widgets by mapping with key={id}, and translate the drag handlers to state updates — dragover computes the target index exactly as here (closest widget + leading/trailing test) but calls a reorder(draggedId, targetIndex) that splices the array, letting React re-render the new order; because keys are stable, React moves the same DOM nodes and the live-reflow preview behaves identically. Persistence becomes a useEffect on the layout state. Angular mirrors this with a signal array and @for (track widget.id), or you can adopt the CDK's DragDropModule which implements the placeholder pattern natively. Tailwind styling maps directly: the grid is grid grid-cols-2 gap-3.5 max-[440px]:grid-cols-1; widgets are bg-slate-800 border border-slate-700 rounded-xl overflow-hidden with data-[dragging]:opacity-35 data-[dragging]:border-dashed and data-[target]:border-indigo-500 data-[target]:ring-[3px] data-[target]:ring-indigo-500/25 variants; wide is col-span-2 max-[440px]:col-auto.