Build drag and drop as an input-independent move engine. Sensors translate pointer, touch, pen, keyboard, and menu actions into one session model. A geometry layer finds valid destinations, the preview shows intent without mutating data, and a transaction layer commits at most one stable move operation with rollback and undo.
A draggable card is easy to demo and surprisingly hard to trust. The trouble starts when a finger scrolls instead of dragging, two drop zones overlap, a list moves under auto-scroll, a keyboard user needs the same outcome, or the server rejects an optimistic reorder. A reusable framework has to make those cases ordinary.
Start with a move intent, not DOM movement
The framework should describe what the user means before it changes application data. A move intent contains a stable source ID, a destination container, an anchor or insertion position, and an operation such as move, copy, or link. Pointer coordinates are evidence used to derive that intent. They are not the persisted result.
Keep four concerns separate:
- sensors turn input events into activation, movement, release, and cancellation;
- geometry and policy choose a compatible destination;
- presentation draws the preview, placeholder, indicators, and announcements;
- the host application validates and persists a move intent.
This separation lets a keyboard command, a touch drag, and a visible "Move to" menu produce the same transaction. It also keeps visual experiments out of ordering logic.
The public interview prompt
Design a reusable drag-and-drop framework for a large web product. Explain:
- pointer, touch, pen, keyboard, and non-dragging pointer alternatives;
- activation constraints, pointer capture, cancellation, and native browser behavior;
- draggable and drop-target registration, nested targets, portals, and virtualization;
- geometry measurement, hit testing, insertion edges, axis locking, and auto-scroll;
- previews, placeholders, focus, screen-reader announcements, and reduced motion;
- move, copy, and link intents across lists and constrained item types;
- optimistic updates, idempotent persistence, conflicts, rollback, and undo;
- performance budgets, cleanup, observability, testing, and staged adoption.
Assume a workspace may register 2,000 mounted candidates across nested scroll containers. A typical interaction moves one item within or between ordered lists. Collaborative updates can change neighboring items while a drag is active. These are design assumptions, not measured product facts. Operating-system file transfer, freehand drawing, and cross-origin dragging are outside version one.
What the premium solution covers
The complete solution defines sensor and adapter contracts, an explicit session state machine, geometry snapshots, deterministic nested hit testing, edge-based insertion, auto-scroll ownership, accessible alternatives, announcements, preview rendering, virtualized targets, a stable move-operation API, optimistic reconciliation, rollback, undo, security boundaries, metrics, tests, and an interview scoring rubric.
Original media follows a pointer session from press through commit, maps one coordinate into nested semantic targets, compares equivalent input paths, and traces an optimistic operation through acknowledgement or correction. Two deterministic labs expose target selection and transaction reconciliation without relying on browser drag events or a backend.