Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to master, this PR will be updated.
Releases
@dnd-kit/core@5.0.0
Major Changes
#558
f3ad20d
Thanks @clauderic! - Refactor of theCollisionDetection
interface to return an array ofCollision
s:This is a breaking change that requires all collision detection strategies to be updated to return an array of
Collision
rather than a singleUniqueIdentifier
The
over
property remains a singleUniqueIdentifier
, 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
andonDragEnd
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:
Consumers can also access the array of collisions in components wrapped by
<DndContext>
via theuseDndContext()
hook:#561
02edd26
Thanks @clauderic! - Droppable containers now observe the node they are attached to viasetNodeRef
usingResizeObserver
while dragging.This behaviour can be configured using the newly introduced
resizeObserverConfig
property.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 droppableid
s 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 sameSortableContext
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
usinguseDndContext()
, thewillRecomputeLayouts
property has been renamed tomeasuringScheduled
, and therecomputeLayouts
method has been renamed tomeasureDroppableContainers
, and now optionally accepts an array of droppableUniqueIdentifier
that should be scheduled to be re-measured.#518
6310227
Thanks @clauderic! - Major internal refactor of measuring and collision detection.Summary of changes
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.
Breaking changes:
@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 ofClientRect
.ClientRect
interface no longer holds theoffsetTop
andoffsetLeft
properties. For most use-cases, you can replaceoffsetTop
withtop
andoffsetLeft
withleft
.@dnd-kit/core
package withgetClientRect
:getBoundingClientRect
getViewRect
getLayoutRect
getViewportLayoutRect
translatedRect
from theSensorContext
interface. Replace usage withcollisionRect
.activeNodeClientRect
on theDndContext
interface. Replace withactiveNodeRect
.#569
e7ac3d4
Thanks @clauderic! - Separated context into public and internal context providers. Certain properties that used to be available on the publicDndContextDescriptor
interface have been moved to the internal context provider and are no longer exposed to consumers: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
anduseSortable
.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 asuseDraggable
anduseDroppable
as children of<DragOverlay>
without causing interference or namespace collisions.Consumers can still make calls to
useDndContext()
to get theactive
orover
properties if they wish to re-render the component rendered withinDragOverlay
in response to user interaction, since those use thePublicContext
Minor Changes
c6c67cb
Thanks @avgrad! - - Added pointer coordinates to collision detectionpointerWithin
collision algorithmPatch Changes
6310227
,528c67e
,02edd26
]:@dnd-kit/sortable@6.0.0
Major Changes
#518
6310227
Thanks @clauderic! - Major internal refactor of measuring and collision detection.Summary of changes
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.
Breaking changes:
@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 ofClientRect
.ClientRect
interface no longer holds theoffsetTop
andoffsetLeft
properties. For most use-cases, you can replaceoffsetTop
withtop
andoffsetLeft
withleft
.@dnd-kit/core
package withgetClientRect
:getBoundingClientRect
getViewRect
getLayoutRect
getViewportLayoutRect
translatedRect
from theSensorContext
interface. Replace usage withcollisionRect
.activeNodeClientRect
on theDndContext
interface. Replace withactiveNodeRect
.#569
e7ac3d4
Thanks @clauderic! - Separated context into public and internal context providers. Certain properties that used to be available on the publicDndContextDescriptor
interface have been moved to the internal context provider and are no longer exposed to consumers: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
anduseSortable
.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 asuseDraggable
anduseDroppable
as children of<DragOverlay>
without causing interference or namespace collisions.Consumers can still make calls to
useDndContext()
to get theactive
orover
properties if they wish to re-render the component rendered withinDragOverlay
in response to user interaction, since those use thePublicContext
Minor Changes
#558
f3ad20d
Thanks @clauderic! - Refactor of theCollisionDetection
interface to return an array ofCollision
s:This is a breaking change that requires all collision detection strategies to be updated to return an array of
Collision
rather than a singleUniqueIdentifier
The
over
property remains a singleUniqueIdentifier
, 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
andonDragEnd
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:
Consumers can also access the array of collisions in components wrapped by
<DndContext>
via theuseDndContext()
hook:#561
02edd26
Thanks @clauderic! - Droppable containers now observe the node they are attached to viasetNodeRef
usingResizeObserver
while dragging.This behaviour can be configured using the newly introduced
resizeObserverConfig
property.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 droppableid
s 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 sameSortableContext
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
usinguseDndContext()
, thewillRecomputeLayouts
property has been renamed tomeasuringScheduled
, and therecomputeLayouts
method has been renamed tomeasureDroppableContainers
, and now optionally accepts an array of droppableUniqueIdentifier
that should be scheduled to be re-measured.#570
1ade2f3
Thanks @clauderic! - Usetransition
for the active draggable node when keyboard sorting without a<DragOverlay />
.Patch Changes
#566
d315df0
Thanks @clauderic! - Fixed a bug where sortable item position was not updated when quickly dragging different sortable items.Updated dependencies [
f3ad20d
,02edd26
,c6c67cb
,6310227
,e7ac3d4
,528c67e
,02edd26
]:@dnd-kit/modifiers@5.0.0
Minor Changes
#567
cd3adf3
Thanks @clauderic! - Update modifiers to usedraggingNodeRect
instead ofactiveNodeRect
. Modifiers should be based on the rect of the node being dragged, whether it is the draggable node or drag overlay node.#518
6310227
Thanks @clauderic! - Major internal refactor of measuring and collision detection.Summary of changes
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.
Breaking changes:
@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 ofClientRect
.ClientRect
interface no longer holds theoffsetTop
andoffsetLeft
properties. For most use-cases, you can replaceoffsetTop
withtop
andoffsetLeft
withleft
.@dnd-kit/core
package withgetClientRect
:getBoundingClientRect
getViewRect
getLayoutRect
getViewportLayoutRect
translatedRect
from theSensorContext
interface. Replace usage withcollisionRect
.activeNodeClientRect
on theDndContext
interface. Replace withactiveNodeRect
.Patch Changes
f3ad20d
,02edd26
,c6c67cb
,6310227
,e7ac3d4
,528c67e
,02edd26
]:@dnd-kit/utilities@3.1.0
Minor Changes
#518
6310227
Thanks @clauderic! - Major internal refactor of measuring and collision detection.Summary of changes
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.
Breaking changes:
@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 ofClientRect
.ClientRect
interface no longer holds theoffsetTop
andoffsetLeft
properties. For most use-cases, you can replaceoffsetTop
withtop
andoffsetLeft
withleft
.@dnd-kit/core
package withgetClientRect
:getBoundingClientRect
getViewRect
getLayoutRect
getViewportLayoutRect
translatedRect
from theSensorContext
interface. Replace usage withcollisionRect
.activeNodeClientRect
on theDndContext
interface. Replace withactiveNodeRect
.528c67e
Thanks @clauderic! - Introduced theuseLatestValue
hook, which returns a ref that holds the latest value of a given argument. Optionally, the second argument can be used to customize the dependencies passed to the effect.Patch Changes
02edd26
Thanks @clauderic! - - TheuseNodeRef
hook'sonChange
argument now receives both the current node and the previous node that were attached to the ref.onChange
argument is only called if the previous node differs from the current node