dnd kit – a lightweight React library for building performant and accessible drag and drop experiences
@dnd-kit – a lightweight React library for building performant and accessible drag and drop experiences.
To get started, install the @dnd-kit/core package via npm or yarn:
clauderic
npm install @dnd-kit/coreVisit docs.dndkit.com to learn how to get started with @dnd-kit.
62f632a Thanks @clauderic! - Added Tab to the list of default key codes that end a drag and drop operation. Can be customized by passing in a custom list of keyCodes to the KeyboardSensor options.#1539 0c6a28d Thanks @irobot! - Make it possible to add visual cues when using activation constraints.
Activation constraints are used when we want to prevent accidental dragging or when pointer press can mean more than "start dragging".
A typical use case is a button that needs to respond to both "click" and "drag" gestures. Clicks can be distinguished from drags based on how long the pointer was held pressed.
A control that responds differently to a pointer press based on duration or distance can be confusing to use -- the user has to guess how long to keep holding or how far to keep dragging until their intent is acknowledged.
Implementing such cues is currently possible by attaching extra event listeners so that we know when a drag is pending. Furthermore, the listener needs to have access to the same constraints that were applied to the sensor initiating the drag. This can be made to work in simple cases, but it becomes error-prone and difficult to maintain in complex scenarios.
This changeset proposes the addition of two new events: onDragPending and onDragAbort.
onDragPendingA drag is considered to be pending when the pointer has been pressed and there are activation constraints that need to be satisfied before a drag can start.
This event is initially fired on pointer press. At this time offset (see below) will be
undefined.
It will subsequently be fired every time the pointer is moved. This is to enable visual cues for distance-based activation.
The event's payload contains all the information necessary for providing visual feedback:
export interface DragPendingEvent {
id: UniqueIdentifier;
constraint: PointerActivationConstraint;
initialCoordinates: Coordinates;
offset?: Coordinates | undefined;
}onDragAbortA drag is considered aborted when an activation constraint for a pending drag was violated. Useful as a prompt to cancel any visual cue animations currently in progress. Note that this event will not be fired when dragging ends or is canceled.
#1494 00ec286 Thanks @dinkinflickaa! - Improves performance by eliminating wasteful re-renders on every child item on click
#1400 995dc23 Thanks @12joan! - Export defaultKeyboardCoordinateGetter
#1542 f629ec6 Thanks @clauderic! - Fix bug with draggable and sortable elements with an id equal to 0.
#1541 99643f6 Thanks @clauderic! - Handle touchcancel and pointercancel events.
#1435 6bbe39b Thanks @knaveenkumar3576! - Faster Paint with delayed flush of Effects
#1543 bcaf7c4 Thanks @clauderic! - Fix a bug with auto-scroller continuing to observe stale elements, causing them to be considered as scrollable.
Updated dependencies [93602df]:
#1271 bc588c7 Thanks @clauderic! - Introduce bypassActivationConstraint() option for PointerSensor, MouseSensor and TouchSensor. This optional argument can be used to conditionally bypass activation constraints. An example use-case would be to bypass activation constraints when the activator event target is the activatorNode of a draggable source.
useSensor(PointerSensor, {
activationConstraint: {
delay: 250,
tolerance: 5,
},
bypassActivationConstraint({event, activeNode}) {
return activeNode.activatorNode.current?.contains(event.target);
},
});#1269 b417f0f Thanks @clauderic! - Allow delay and distance activation constraints to be used concurrently for MouseSensor, TouchSensor and PointerSensor.
da888ee Thanks @WillDonohoe! - Fix errors with calls to getComputedStyle in Firefox when destructuring from the window objectda94c02 Thanks @clauderic! - Bug fixes for React 18 Strict ModeUpdated dependencies [da7c60d]:
4a5132d Thanks @clauderic! - Removed a stray console.log in the KeyboardSensoreaa6e12 Thanks @clauderic! - Fixed a regression in the KeyboardSensor scrolling logic.e97cb1f Thanks @clauderic! - The ARIA live region element used for screen reader announcements is now positioned using position: fixed instead of position: absolute. As of @dnd-kit/core^6.0.0, the live region element is no longer portaled by default into the document.body. This change was introduced in order to fix issues with portaled live regions. However, this change can introduce visual regressions when using absolutely positioned elements, since the live region element is constrained to the stacking and position context of its closest positioned ancestor. Using fixed position ensures the element does not introduce visual regressions.#769 8e3599f Thanks @clauderic! - Fixed an issue with the containerNodeRect that is exposed to modifiers having stale properties (top, left, etc.) when its scrollable ancestors were scrolled.
#769 53cb962 Thanks @clauderic! - Fixed a regression with scrollable ancestors detection.
The scrollable ancestors should be determined by the active node or the over node exclusively. The draggingNode variable shouldn't be used to detect scrollable ancestors since it can be the drag overlay node, and the drag overlay node doesn't have any scrollable ancestors because it is a fixed position element.
e5b9d38 Thanks @clauderic! - Fixed a regression with the default drop animation of <DragOverlay> for consumers using React 18.#746 4173087 Thanks @clauderic! - Accessibility related changes.
Accessibility-related props have been regrouped under the accessibility prop of <DndContext>:
<DndContext
- announcements={customAnnouncements}
- screenReaderInstructions={customScreenReaderInstructions}
+ accessibility={{
+ announcements: customAnnouncements,
+ screenReaderInstructions: customScreenReaderInstructions,
+ }}This is a breaking change that will allow easier addition of new accessibility-related features without overloading the props namespace of <DndContext>.
The arguments passed to announcement callbacks have changed. They now receive an object that contains the active and over properties that match the signature of those passed to the DragEvent handlers (onDragStart, onDragMove, etc.). This change allows consumers to read the data property of the active and over node to customize the announcements based on the data.
Example migration steps:
export const announcements: Announcements = {
- onDragStart(id) {
+ onDragStart({active}) {
- return `Picked up draggable item ${id}.`;
+ return `Picked up draggable item ${active.id}.`;
},
- onDragOver(id, overId) {
+ onDragOver({active, over}) {
- if (overId) {
+ if (over) {
- return `Draggable item ${id} was moved over droppable area ${overId}.`;
+ return `Draggable item ${active.id} was moved over droppable area ${over.id}.`;
}
- return `Draggable item ${id} is no longer over a droppable area.`;
+ return `Draggable item ${active.id} is no longer over a droppable area.`;
},
};The DOM nodes for the screen reader instructions and announcements are no longer portaled into the document.body element by default.
This change is motivated by the fact that screen readers do not always announce ARIA live regions that are rendered on the document.body. Common examples of this include when rendering a <DndContext> within a <dialog> element or an element that has role="dialog", only ARIA live regions rendered within the dialog will be announced.
Consumers can now opt to render announcements in the portal container of their choice using the container property of the accessibility prop:
<DndContext
+ accessibility={{
+ container: document.body,
+ }}#733 035021a Thanks @clauderic! - The <DragOverlay> component's drop animation has been refactored, which fixes a number of bugs with the existing implementation and introduces new functionality.
The drop animation now ensures that the the draggable node that we are animating to is in the viewport before performing the drop animation and scrolls it into view if needed.
dropAnimation propThe dropAnimation prop of <DragOverlay> now accepts either a configuration object or a custom drop animation function.
The configuration object adheres to the following shape:
interface DropAnimationOptions {
duration?: number;
easing?: string;
keyframes?: DropAnimationKeyframeResolver;
sideEffects?: DropAnimationSideEffects;
}The default drop animation options are:
const defaultDropAnimationConfiguration: DropAnimationOptions = {
duration: 250,
easing: 'ease',
keyframes: defaultDropAnimationKeyframes,
sideEffects: defaultDropAnimationSideEffects({
styles: {
active: {
opacity: '0',
},
},
}),
};The keyframes option allows consumers to override the keyframes of the drop animation. For example, here is how you would add a fade out transition to the drop animation using keyframes:
import {CSS} from '@dnd-kit/utilities';
const customDropAnimation = {
keyframes({transform}) {
return [
{opacity: 1, transform: CSS.Transform.toString(transform.initial)},
{opacity: 0, transform: CSS.Transform.toString(transform.final)},
];
},
};The dragSourceOpacity option has been deprecated in favour of letting consumers define arbitrary side effects that should run before the animation starts. Side effects may return a cleanup function that should run when the drop animation has completed.
type CleanupFunction = () => void;
export type DropAnimationSideEffects = (
parameters: DropAnimationSideEffectsParameters
) => CleanupFunction | void;Drop animation side effects are a powerful abstraction that provide a lot of flexibility. The defaultDropAnimationSideEffects function is exported by @dnd-kit/core and aims to facilitate the types of side-effects we anticipate most consumers will want to use out of the box:
interface DefaultDropAnimationSideEffectsOptions {
// Apply a className on the active draggable or drag overlay node during the drop animation
className?: {
active?: string;
dragOverlay?: string;
};
// Apply temporary styles to the active draggable node or drag overlay during the drop animation
styles?: {
active?: Styles;
dragOverlay?: Styles;
};
}For advanced side-effects, consumers may define a custom sideEffects function that may optionally return a cleanup function that will be executed when the drop animation completes:
const customDropAnimation = {
sideEffects({active}) {
active.node.classList.add('dropAnimationInProgress');
active.node.animate([{opacity: 0}, {opacity: 1}], {
easing: 'ease-in',
duration: 250,
});
return () => {
// Clean up when the drop animation is complete
active.node.classList.remove('dropAnimationInProgress');
};
},
};For even more advanced use-cases, consumers may also provide a function to the dropAnimation prop, which adheres to the following shape:
interface DropAnimationFunctionArguments {
active: {
id: UniqueIdentifier;
data: DataRef;
node: HTMLElement;
rect: ClientRect;
};
draggableNodes: DraggableNodes;
dragOverlay: {
node: HTMLElement;
rect: ClientRect;
};
droppableContainers: DroppableContainers;
measuringConfiguration: DeepRequired<MeasuringConfiguration>;
transform: Transform;
}
type DropAnimationFunction = (
args: DropAnimationFunctionArguments
) => Promise<void> | void;<DragOverlay> now respects the measuringConfiguration specified for the dragOverlay and draggable properties when measuring the rects to animate to and from.<DragOverlay> component now supports rendering children while performing the drop animation. Previously, the drag overlay would be in a broken state when trying to pick up an item while a drop animation was in progress.For consumers that were relying on the dragSourceOpacity property in their dropAnimation configuration:
+ import {defaultDropAnimationSideEffects} from '@dnd-kit/core';
const dropAnimation = {
- dragSourceOpacity: 0.5,
+ sideEffects: defaultDropAnimationSideEffects({
+ styles : {
+ active: {
+ opacity: '0.5',
+ },
+ },
+ ),
};#745 5f3c700 Thanks @clauderic! - The keyboard sensor now keeps track of the initial coordinates of the collision rect to provide a translate delta when move events are dispatched.
This is a breaking change that may affect consumers that had created custom keyboard coordinate getters.
Previously the keyboard sensor would measure the initial rect of the active node and store its top and left properties as its initial coordinates it would then compare all subsequent move coordinates to calculate the delta.
This approach suffered from the following issues:
<DndContext> for the draggable nodecurrentCoordinates passed to the coordinate getter were often stale and not an accurate representation of the current position of the collision rect, which can be affected by a number of different variables, such as modifiers.#755 33e6dd2 Thanks @clauderic! - The UniqueIdentifier type has been updated to now accept either string or number identifiers. As a result, the id property of useDraggable, useDroppable and useSortable and the items prop of <SortableContext> now all accept either string or number identifiers.
For consumers that are using TypeScript, import the UniqueIdentifier type to have strongly typed local state:
+ import type {UniqueIdentifier} from '@dnd-kit/core';
function MyComponent() {
- const [items, setItems] = useState(['A', 'B', 'C']);
+ const [items, setItems] = useState<UniqueIdentifier>(['A', 'B', 'C']);
}Alternatively, consumers can cast or convert the id property to a string when reading the id property of interfaces such as Active, Over, DroppableContainer and DraggableNode.
The draggableNodes object has also been converted to a map. Consumers that were reading from the draggableNodes property that is available on the public context of <DndContext> should follow these migration steps:
- draggableNodes[someId];
+ draggableNodes.get(someId);#748 59ca82b Thanks @clauderic! - Automatic focus management and activator node refs.
Introducing the concept of activator node refs for useDraggable and useSortable. This allows @dnd-kit to handle common use-cases such as restoring focus on the activator node after dragging via the keyboard or only allowing the activator node to instantiate the keyboard sensor.
Consumers of useDraggable and useSortable may now optionally set the activator node ref on the element that receives listeners:
import {useDraggable} from '@dnd-kit/core';
function Draggable(props) {
const {
listeners,
setNodeRef,
+ setActivatorNodeRef,
} = useDraggable({id: props.id});
return (
<div ref={setNodeRef}>
Draggable element
<button
{...listeners}
+ ref={setActivatorNodeRef}
>
:: Drag Handle
</button>
</div>
)
}It's common for the activator element (the element that receives the sensor listeners) to differ from the draggable node. When this happens, @dnd-kit has no reliable way to get a reference to the activator node after dragging ends, as the original event.target that instantiated the sensor may no longer be mounted in the DOM or associated with the draggable node that was previously active.
Focus management is now automatically handled by @dnd-kit. When the activator event is a Keyboard event, @dnd-kit will now attempt to automatically restore focus back to the first focusable node of the activator node or draggable node.
If no activator node is specified via the setActivatorNodeRef setter function of useDraggble and useSortable, @dnd-kit will automatically restore focus on the first focusable node of the draggable node set via the setNodeRef setter function of useDraggable and useSortable.
If you were previously managing focus manually and would like to opt-out of automatic focus management, use the newly introduced restoreFocus property of the accessibility prop of <DndContext>:
<DndContext
accessibility={{
+ restoreFocus: false
}}#751 a52fba1 Thanks @clauderic! - Added the aria-disabled attribute to the attribtues object returned by useDraggable and useSortable. The value of the aria-disabled attribute is populated based on whether or not the disabled argument is passed to useDraggble or useSortable.
#741 40707ce Thanks @clauderic! - The auto scroller now keeps track of the drag direction to infer scroll intent. By default, auto-scrolling will now be disabled for a given direction if dragging in that direction hasn't occurred yet. This prevents accidental auto-scrolling when picking up a draggable item that is near the scroll boundary threshold.
#660 a41e5b8 Thanks @clauderic! - Fixed a bug with the delta property returned in onDragMove, onDragOver, onDragEnd and onDragCancel. The delta property represents the transform delta since dragging was initiated, along with the scroll delta. However, due to an oversight, the delta property was actually returning the transform delta and the current scroll offsets rather than the scroll delta.
This same change has been made to the scrollAdjustedTranslate property that is exposed to sensors.
#750 bf30718 Thanks @clauderic! - The useDndMonitor() hook has been refactored to be synchronously invoked at the same time as the events dispatched by <DndContext> (such as onDragStart, onDragOver, onDragEnd).
The new refactor uses the subscribe/notify pattern and no longer causes re-renders in consuming components of useDndMonitor() when events are dispatched.
#660 a41e5b8 Thanks @clauderic! - The activeNodeRect and containerNodeRect are now observed by a ResizeObserver in case they resize while dragging.
#660 a41e5b8 Thanks @clauderic! - Improved useDraggable usage without <DragOverlay>:
<DragOverlay> used.#660 77e3d44 Thanks @clauderic! - Fixed an issue with useDroppable hook needlessly dispatching SetDroppableDisabled actions even if the disabled property had not changed since registering the droppable.
#749 188a450 Thanks @clauderic! - The onDragStart, onDragMove, onDragOver, onDragEnd and onDragCancel events of <DndContext> and useDndMonitor now expose the activatorEvent event that instantiated the activated sensor.
#733 035021a Thanks @clauderic! - The KeyboardSensor now scrolls the focused activator draggable node into view if it is not within the viewport.
#733 035021a Thanks @clauderic! - By default, @dnd-kit now attempts to compensate for layout shifts that happen right after the onDragStart event is dispatched by scrolling the first scrollable ancestor of the active draggable node.
The autoScroll prop of <DndContext> now optionally accepts a layoutShiftCompensation property to control this new behavior:
interface AutoScrollOptions {
acceleration?: number;
activator?: AutoScrollActivator;
canScroll?: CanScroll;
enabled?: boolean;
interval?: number;
+ layoutShiftCompensation?: boolean | {x: boolean, y: boolean};
order?: TraversalOrder;
threshold?: {
x: number;
y: number;
};
}To enable/disable layout shift scroll compensation for a single scroll axis, pass in the following autoscroll configuration to <DndContext>:
<DndContext
autoScroll={{layoutShiftCompensation: {x: false, y: true}}}
>To completely disable layout shift scroll compensation, pass in the following autoscroll configuration to <DndContext>:
<DndContext
autoScroll={{layoutShiftCompensation: false}}
>#672 10f6836 Thanks @clauderic! - The measureDroppableContainers method now properly respects the MeasuringStrategy defined on <DndContext /> and will not measure containers while measuring is disabled.
#656 c1b3b5a Thanks @clauderic! - Fixed an issue with collision detection using stale rects. The droppableRects property has been added to the CollisionDetection interface.
All built-in collision detection algorithms have been updated to get the rect for a given droppable container from droppableRects rather than from the rect.current ref:
- const rect = droppableContainers.get(id).rect.current;
+ const rect = droppableRects.get(id);The rect.current ref stored on DroppableContainers can be stale if measuring is scheduled but has not completed yet. Collision detection algorithms should use the droppableRects map instead to get the latest, most up-to-date measurement of a droppable container in order to avoid computing collisions against stale rects.
This is not a breaking change. However, if you've forked any of the built-in collision detection algorithms or you've authored custom ones, we highly recommend you update your use-cases to avoid possibly computing collisions against stale rects.
#742 7161f70 Thanks @clauderic! - Fallback to initial rect measured for the active draggable node if it unmounts during initialization (after onDragStart is dispatched).
#749 5811986 Thanks @clauderic! - The Data and DataRef types are now exported by @dnd-kit/core.
#699 e302bd4 Thanks @JuAn-Kang! - Export DragOverlayProps for consumers.
750d726 Thanks @clauderic! - Fixed a bug in the KeyboardSensor where it would not move the draggable on the horizontal axis if it could fully scroll to the new vertical coordinates, and would not move the draggable on the vertical axis if it could fully scroll to the new horizontal coordinates.
#660 e6e242c Thanks @clauderic! - The KeyboardSensor was updated to use scrollTo instead of scrollBy when it is able to fully scroll to the new coordinates returned by the coordinate getter function. This resolves issues that can happen with scrollBy when called in rapid succession.
2439aae Thanks @clauderic! - - Fixed React warning in development when unmounting a component that uses the useDraggable hook by ensuring that the ResizeObserver is disconnected in a cleanup effect.b3b185d Thanks @lukesmurray! - Export DraggableAttributes interface for consumers to use when interfacing with useDraggable hook.cee1d88 Thanks @clauderic! - Only use ResizeObserver in useDroppable and <DragOverlay> if it is available in the execution environment.#558 f3ad20d Thanks @clauderic! - Refactor of the CollisionDetection interface to return an array of Collisions:
+export interface Collision {
+ id: UniqueIdentifier;
+ data?: Record<string, any>;
+}
export type CollisionDetection = (args: {
active: Active;
collisionRect: ClientRect;
droppableContainers: DroppableContainer[];
pointerCoordinates: Coordinates | null;
-}) => UniqueIdentifier;
+}) => Collision[];This is a breaking change that requires all collision detection strategies to be updated to return an array of Collision rather than a single UniqueIdentifier
The over property remains a single UniqueIdentifier, and is set to the first item in returned in the collisions array.
Consumers can also access the collisions property which can be used to implement use-cases such as combining droppables in user-land.
The onDragMove, onDragOver and onDragEnd callbacks are also updated to receive the collisions array property.
Built-in collision detections such as rectIntersection, closestCenter, closestCorners and pointerWithin adhere to the CollisionDescriptor interface, which extends the Collision interface:
export interface CollisionDescriptor extends Collision {
data: {
droppableContainer: DroppableContainer;
value: number;
[key: string]: any;
};
}Consumers can also access the array of collisions in components wrapped by <DndContext> via the useDndContext() hook:
import {useDndContext} from '@dnd-kit/core';
function MyComponent() {
const {collisions} = useDndContext();
}#561 02edd26 Thanks @clauderic! - Droppable containers now observe the node they are attached to via setNodeRef using ResizeObserver while dragging.
This behaviour can be configured using the newly introduced resizeObserverConfig property.
interface ResizeObserverConfig {
/** Whether the ResizeObserver should be disabled entirely */
disabled?: boolean;
/** Resize events may affect the layout and position of other droppable containers.
* Specify an array of `UniqueIdentifier` of droppable containers that should also be re-measured
* when this droppable container resizes. Specifying an empty array re-measures all droppable containers.
*/
updateMeasurementsFor?: UniqueIdentifier[];
/** Represents the debounce timeout between when resize events are observed and when elements are re-measured */
timeout?: number;
}By default, only the current droppable is scheduled to be re-measured when a resize event is observed. However, this may not be suitable for all use-cases. When an element resizes, it can affect the layout and position of other elements, such that it may be necessary to re-measure other droppable nodes in response to that single resize event. The recomputeIds property can be used to specify which droppable ids should be re-measured in response to resize events being observed.
For example, the useSortable preset re-computes the measurements of all sortable elements after the element that resizes, so long as they are within the same SortableContext as the element that resizes, since it's highly likely that their layout will also shift.
Specifying an empty array for recomputeIds forces all droppable containers to be re-measured.
For consumers that were relyings on the internals of DndContext using useDndContext(), the willRecomputeLayouts property has been renamed to measuringScheduled, and the recomputeLayouts method has been renamed to measureDroppableContainers, and now optionally accepts an array of droppable UniqueIdentifier that should be scheduled to be re-measured.
#518 6310227 Thanks @clauderic! - Major internal refactor of measuring and collision detection.
Previously, all collision detection algorithms were relative to the top and left points of the document. While this approach worked in most situations, it broke down in a number of different use-cases, such as fixed position droppable containers and trying to drag between containers that had different scroll positions.
This new approach changes the frame of comparison to be relative to the viewport. This is a major breaking change, and will need to be released under a new major version bump.
@dnd-kit now ignores only the transforms applied to the draggable / droppable node itself, but considers all the transforms applied to its ancestors. This should provide the right balance of flexibility for most consumers.ViewRect, LayoutRect to just a single concept of ClientRect.ClientRect interface no longer holds the offsetTop and offsetLeft properties. For most use-cases, you can replace offsetTop with top and offsetLeft with left.@dnd-kit/core package with getClientRect:getBoundingClientRectgetViewRectgetLayoutRectgetViewportLayoutRecttranslatedRect from the SensorContext interface. Replace usage with collisionRect.activeNodeClientRect on the DndContext interface. Replace with activeNodeRect.#569 e7ac3d4 Thanks @clauderic! - Separated context into public and internal context providers. Certain properties that used to be available on the public DndContextDescriptor interface have been moved to the internal context provider and are no longer exposed to consumers:
interface DndContextDescriptor {
- dispatch: React.Dispatch<Actions>;
- activators: SyntheticListeners;
- ariaDescribedById: {
- draggable: UniqueIdentifier;
- };
}Having two distinct context providers will allow to keep certain internals such as dispatch hidden from consumers.
It also serves as an optimization until context selectors are implemented in React, properties that change often, such as the droppable containers and droppable rects, the transform value and array of collisions should be stored on a different context provider to limit un-necessary re-renders in useDraggable, useDroppable and useSortable.
The <InternalContext.Provider> is also reset to its default values within <DragOverlay>. This paves the way towards being able to seamlessly use components that use hooks such as useDraggable and useDroppable as children of <DragOverlay> without causing interference or namespace collisions.
Consumers can still make calls to useDndContext() to get the active or over properties if they wish to re-render the component rendered within DragOverlay in response to user interaction, since those use the PublicContext
c6c67cb Thanks @avgrad! - - Added pointer coordinates to collision detectionpointerWithin collision algorithm#509 1c6369e Thanks @clauderic! - Helpers have been updated to support rendering in foreign window contexts (via ReactDOM.render or ReactDOM.createPortal).
For example, checking if an element is an instance of an HTMLElement is normally done like so:
if (element instanceof HTMLElement)However, when rendering in a different window, this can return false even if the element is indeed an HTMLElement, because this code is equivalent to:
if (element instanceof window.HTMLElement)And in this case, the window of the element is different from the main execution context window, because we are rendering via a portal into another window.
This can be solved by finding the local window of the element:
const elementWindow = element.ownerDocument.defaultView;
if (element instanceof elementWindow.HTMLElement)Updated dependencies [1c6369e]:
d973cc6 Thanks @clauderic! - Sensors that extend the AbstractPointerSensor now prevent HTML Drag and Drop API events from being triggered while the sensor is activated.5ec3310 Thanks @mdrobny! - fix: bind handleCancel handler in AbstractPointerSensor to current execution context (this).#337 05d6a78 Thanks @clauderic! - React updates in non-synthetic event handlers are now batched to reduce re-renders and prepare for React 18.
Also fixed issues with collision detection:
#427 f96cb5d Thanks @clauderic! - - Using transform-agnostic measurements for the DragOverlay node.
overlayNode property to dragOverlay on the DndContextDescriptor interface.#372 dbc9601 Thanks @clauderic! - Refactored DroppableContainers type from Record<UniqueIdentifier, DroppableContainer to a custom instance that extends the Map constructor and adds a few other methods such as toArray(), getEnabled() and getNodeFor(id).
A unique key property was also added to the DraggableNode and DroppableContainer interfaces. This prevents potential race conditions in the mount and cleanup effects of useDraggable and useDroppable. It's possible for the clean-up effect to run after another React component using useDraggable or useDroppable mounts, which causes the newly mounted element to accidentally be un-registered.
#379 8d70540 Thanks @clauderic! - The layoutMeasuring prop of DndContext has been renamed to measuring.
The options that could previously be passed to the layoutMeasuring prop now need to be passed as:
<DndContext
- layoutMeasuring={options}
+ measuring={{
+ droppable: options
+ }}The LayoutMeasuring type has been renamed to MeasuringConfiguration. The LayoutMeasuringStrategy and LayoutMeasuringFrequency enums have also been renamed to MeasuringStrategy and MeasuringFrequency.
This refactor allows consumers to configure how to measure both droppable and draggable nodes. By default, @dnd-kit ignores transforms when measuring draggable nodes. This beahviour can now be configured:
import {
DndContext,
getBoundingClientRect,
MeasuringConfiguration,
} from '@dnd-kit/core';
const measuringConfig: MeasuringConfiguration = {
draggable: {
measure: getBoundingClientRect,
},
};
function App() {
return <DndContext measuring={measuringConfig} />;
}#350 a13dbb6 Thanks @wmain! - Breaking change: The CollisionDetection interface has been refactored. It now receives an object that contains the active draggable node, along with the collisionRect and an array of droppableContainers.
If you've built custom collision detection algorithms, you'll need to update them. Refer to this PR for examples of how to refactor collision detection functions to the new CollisionDetection interface.
The sortableKeyboardCoordinates method has also been updated since it relies on the closestCorners collision detection algorithm. If you were using collision detection strategies in a custom sortableKeyboardCoordinates method, you'll need to update those as well.
#334 13be602 Thanks @trentmwillis! - Now passing activatorEvent as an argument to modifiers
#376 aede2cc Thanks @clauderic! - Mouse, Pointer, Touch sensors now cancel dragging on visibility change and window resize. The Keyboard sensor already cancelled dragging on window resize. It now also cancels dragging on visibility change.
#399 a32a4c5 Thanks @supersebh! - Added support for tolerance in DistanceConstrain. As soon as the tolerance is exceeded, the drag operation will be aborted, unless it has already started (because distance criteria was met).
Example usage:
// Require the pointer be moved by 10 pixels vertically to initiate drag operation
// Abort if the pointer is moved by more than 5 pixels horizontally.
{
distance: {y: 10},
tolerance: {x: 5},
}Be careful not to pick conflicting settings for distance and tolerance if used together. For example, picking a tolerance that is lower than the distance in the same axis would result in the activation constraint never being met.
#408 dea715c Thanks @wmain! - The collision rect is now completely based on the position of the DragOverlay when it is used. Previously, only the width and height properties of the DragOverlay were used for the collision rect, while the top, left, bottom and right properties were derived from the active node rect. This new approach is more aligned with developers would expect, but could cause issues for consumers that were relying on the previous (incorrect) behavior.
#433 c447880 Thanks @clauderic! - Fix unwanted animations when items in sortable context change
#415 2ba6dfe Thanks @cantrellnm! - Prevent getScrollableAncestors from continuing to search if a fixed position node is found.
#377 422d083 Thanks @clauderic! - Pointer, Mouse and Touch sensors now stop propagation of click events once activation constraints are met.
#375 c4b21b4 Thanks @clauderic! - Prevent context menu from opening when pointer sensor is active
5a41340 Thanks @clauderic! - Pointer, Mouse and Touch sensors now prevent selection changes and clear any existing selection ranges once activation constraints are met.
e2ee0dc Thanks @clauderic! - Reset the over internal state of <DndContext /> on drop.
1fe9b5c Thanks @clauderic! - Sensors may now specify a static setup method that will be invoked when <DndContext> mounts. The setup method may optionally also return a teardown function that will be invoked when the <DndContext> associated with that sensor unmounts.
#430 46ec5e4 Thanks @clauderic! - Fix duplicate scroll ancestor detection. In some scenarios, an element could be added twice to the list of detected scrollable ancestors, resulting in invalid offsets.
#371 7006464 Thanks @clauderic! - fix: do not wrap consumer-defined handlers in batchedUpdates
1fe9b5c Thanks @clauderic! - The TouchSensor attempts to prevent the default browser behavior of scrolling the page by calling event.preventDefault() in the touchmove event listener. This wasn't working in iOS Safari due to a bug with dynamically attached touchmove event listeners. Adding a non-passive, non-capture touchmove event listener before dynamically attaching other touchmove event listeners solves the issue.
dbe0087 #335 Thanks @clauderic! - Fix getEventListenerTarget when target element is not an instance of HTMLElement
5d4d292 #331 Thanks @phungleson! - Fix typo in SensorContext type (scrollAdjustedTransalte --> scrollAdjustedTranslate)
d39ab11 #316 Thanks @lsit! - Added ability to optionally return screen reader announcements onDragMove.ae398de Thanks @clauderic! - Allow setting an optional id prop on DndContext to fix a warning during server-side rendering (especially in Next.js). By default, this id is autogenerated and can lead to a mismatch between the server- and client-side rendered HTML. We also avoid this mismatch by rendering the Accessibility component only after everything else was initially mounted on the client.
8b938ce Thanks @clauderic! - Hide the node in the overlay after the drop animation is finished. This prevents some flickering with React concurrent mode.
0ff788e #246 Thanks @inokawa! - DragOverlay component now passes down style prop to the wrapper element it renders.54c8778 #225 Thanks @clauderic! - Updated the active rects type to ViewRect (was previously incorrectly typed as LayoutRect)
2ee96a5 #243 Thanks @py-wai! - Update regex used in isScrollable, to consider element with overflow: overlay as a scrollable element.
f9ec28f #217 Thanks @clauderic! - Fixes a regression introduced with @dnd-kit/core@3.0.0 that was causeing sensors to stop working after a drag operation where activation constraints were not met.a9d92cf #174 Thanks @clauderic! - Distributed assets now only target modern browsers. Browserlist config:
defaults
last 2 version
not IE 11
not deadIf you need to support older browsers, include the appropriate polyfills in your project's build process.
b406cb9 #187 Thanks @clauderic! - Introduced the useDndMonitor hook. The useDndMonitor hook can be used within components wrapped in a DndContext provider to monitor the different drag and drop events that happen for that DndContext.
Example usage:
import {DndContext, useDndMonitor} from '@dnd-kit/core';
function App() {
return (
<DndContext>
<Component />
</DndContext>
);
}
function Component() {
useDndMonitor({
onDragStart(event) {},
onDragMove(event) {},
onDragOver(event) {},
onDragEnd(event) {},
onDragCancel(event) {},
});
}b7355d1 #207 Thanks @clauderic! - The data argument for useDraggable and useDroppable is now exposed in event handlers and on the active and over objects.
Example usage:
import {DndContext, useDraggable, useDroppable} from '@dnd-kit/core';
function Draggable() {
const {attributes, listeners, setNodeRef, transform} = useDraggable({
id: 'draggable',
data: {
type: 'type1',
},
});
/* ... */
}
function Droppable() {
const {setNodeRef} = useDroppable({
id: 'droppable',
data: {
accepts: ['type1', 'type2'],
},
});
/* ... */
}
function App() {
return (
<DndContext
onDragEnd={({active, over}) => {
if (over?.data.current.accepts.includes(active.data.current.type)) {
// do stuff
}
}}
/>
);
}2833337 #186 Thanks @clauderic! - Simplify useAnnouncement hook to only return a single announcement rather than entries. Similarly, the LiveRegion component now only accepts a single announcement rather than `entries.
bdb1aa2 #171 Thanks @mitchheddles! - Added more flexibility for the distance and tolerance activation constraints. Consumers can still provide a number to calculate the distance or tolerance constraints, but can now also pass in an object that adheres to the DistanceMeasurement interface instead. This change allows consumers to specify which axis the activation distance or tolerance should be measured against, either x, y or both.
type DistanceMeasurement =
| number
| {x: number}
| {y: number}
| {x: number, y: number}
interface DistanceConstraint {
distance: DistanceMeasurement;
}
interface DelayConstraint {
delay: number;
tolerance: DistanceMeasurement;
}Example usage:
For example, when building a list that can only be sorted vertically when using the restrictToVerticalAxis modifier, a consumer can now configure sensors to only measure distance against the y axis when using the MouseSensor, and afford more tolerance on the y axis than the x axis for the TouchSensor:
const sensors = useSensors(
useSensor(MouseSensor, {
activationConstraint: {
distance: { y: 10 },
},
}),
useSensor(TouchSensor, {
activationConstraint: {
delay: 250,
tolerance: { y: 15, x: 5 },
},
}),
);This also fixes a bug with the way the distance is calculated when passing a number to the distance or tolerance options. Previously, the sum of the distance on both the x and y axis was being calculated rather than the hypothenuse.
f038174 #166 Thanks @shayc! - AutoScrollActivator enum was being exported as a type rather than a value.
7422e25 #165 Thanks @clauderic! - Fix regression with autoscroll disabling by sensors
a847a80 #160 Thanks @clauderic! - Allow consumers to define drag source opacity in drop animation by setting the dragSourceOpacity option to a number on the dropAnimation prop of DragOverlay.
ea9d878 #164 Thanks @clauderic! - Export AutoScrollActivator enum for consumers.
8583825 #140 Thanks @clauderic! - Auto-scrolling defaults have been updated, which should generally lead to improved user experience for most consumers.
The auto-scroller now bases its calculations based on the position of the pointer rather than the edges of the draggable element's rect by default. This change is aligned with how the native HTML 5 Drag & Drop auto-scrolling behaves.
This behaviour can be customized using the activator option of the autoScroll prop:
import {AutoScrollActivator, DndContext} from '@dnd-kit/core';
<DndContext autoScroll={{activator: AutoScrollActivator.DraggableRect}} />;The auto-scroller now also looks at scrollable ancestors in order of appearance in the DOM tree, meaning it will first attempt to scroll the window, and narrow its focus down rather than the old behaviour of looking at scrollable ancestors in order of closeness to the draggable element in the DOM tree (reversed tree order).
This generally leads to an improved user experience, but can be customized by passing a configuration object to the autoScroll prop that sets the order option to TraversalOrder.ReversedTreeOrder instead of the new default value of TraversalOrder.TreeOrder:
import {DndContext, TraversalOrder} from '@dnd-kit/core';
<DndContext autoScroll={{order: TraversalOrder.ReversedTreeOrder}} />;The autoscrolling thresholds, acceleration and interval can now also be customized using the autoScroll prop:
import {DndContext} from '@dnd-kit/core';
<DndContext
autoScroll={{
thresholds: {
// Left and right 10% of the scroll container activate scrolling
x: 0.1,
// Top and bottom 25% of the scroll container activate scrolling
y: 0.25,
},
// Accelerate slower than the default value (10)
acceleration: 5,
// Auto-scroll every 10ms instead of the default value of 5ms
interval: 10,
}}
/>;Finally, consumers can now conditionally opt out of scrolling certain scrollable ancestors using the canScroll option of the autoScroll prop:
import {DndContext} from '@dnd-kit/core';
<DndContext
autoScroll={{
canScroll(element) {
if (element === document.scrollingElement) {
return false;
}
return true;
},
}}
/>;79f6088 #144 Thanks @clauderic! - Allow consumers to determine whether to animate layout changes and when to measure nodes. Consumers can now use the animateLayoutChanges prop of useSortable to determine whether layout animations should occur. Consumers can now also decide when to measure layouts, and at what frequency using the layoutMeasuring prop of DndContext. By default, DndContext will measure layouts just-in-time after sorting has begun. Consumers can override this behaviour to either only measure before dragging begins (on mount and after dragging), or always (on mount, before dragging, after dragging). Pairing the layoutMeasuring prop on DndContext and the animateLayoutChanges prop of useSortable opens up a number of new possibilities for consumers, such as animating insertion and removal of items in a sortable list.
a76cd5a #136 Thanks @clauderic! - Added onActivation option to sensors. Delegated the responsibility of calling event.preventDefault() on activation to consumers, as consumers have the most context to decide whether it is appropriate or not to prevent the default browser behaviour on activation. Consumers of the sensors can prevent the default behaviour on activation using the onActivation option. Here is an example using the Pointer sensor: useSensor(PointerSensor, {onActivation: (event) => event.preventDefault()})
adb7bd5 #151 Thanks @clauderic! - DragOverlay now attempts to perform drop animation even if transform.x and transform.y are both zero.ac674e8 #135 Thanks @ranbena! - Added dragCancel prop to DndContext. The dragCancel prop can be used to cancel a drag operation on drop. The prop accepts a function that returns a boolean, or a promise returning a boolean once resolved. Return false to cancel the drop.
208f68e #111 Thanks @ranbena! - Keyboard sensor now cancels dragging on window resize
423610c #56 Thanks @clauderic! - Add MIT license to package.json and distributed files
594a24e #106 Thanks @ranbena! - Replace animation.finished with animation.onfinish for DragOverlay drop animation as the latter has much better support across browsers.
fd25eaf #68 Thanks @Pustelto! - Wrap attributes returned from useDraggable hook in useMemo to allow pure component optimization
Updated dependencies [423610c]:
5194696 #51 Thanks @clauderic! - Fix issue with reducer initial state variable causing collisions due to variable references all pointing to the original initial state variable.
310bbd6 #37 Thanks @nickpresta! - Fix typo in package.json repository URL
2912350 Thanks @clauderic! - Initial public release.2912350]:
2bb3065 Thanks @clauderic! - No longer setting pointer-events to none for DragOverlay component as it interferes with custom cursors.
bf04b2b Thanks @clauderic! - Allow nullish values to be passed to useSensors for conditional sensors.
7bd4568 #30 - Initial beta release, authored by @clauderic.7bd4568]: