2.5.0

Improvements

Droppables now accept an ignoreContainerClipping prop. From the docs:

When a Droppable is inside a scrollable container its area is constrained so that you can only drop on the part of the Droppable that you can see. Setting this prop opts out of this behaviour, allowing you to drop anywhere on a Droppable even if it's visually hidden by a scrollable parent. The default behaviour is suitable for most cases so odds are you'll never need to use this prop, but it can be useful if you've got very long Draggables inside a short scroll container. Keep in mind that it might cause some unexpected behaviour if you have multiple Droppables inside scroll containers on the same page.

This caused the minor version bump ✨

Fixes

• A bunch of docs updates. Thanks @hungle88!

2.4.1

Fixes

• We now include the size of the placeholder in a droppable area's dimensions, when appropriate. During a drag, when hovering over a Droppable that's not the one you lifted from, the size of that Droppable will appear to expand to create a gap for the dragging item. This conditional extra area wasn't being included in the Droppable's hit-box previously, but now it is. #122
• Fixed a bug whereby Droppable dimensions weren't being clipped by their scroll parent when calculating which droppable to move into when moving between lists using the keyboard. #136
• Fixed how we bind event listeners to the window object, which allows the drag-and-drop to be popped out into another window. Thanks @kgorgi!! #139

2.4.0

Improvements

• We now allow hooks to be updated dynamically (caused the minor version bump ✨). Previously the onDragStart and onDragEnd callbacks were captured once on mount, and any subsequent updates to these props would not be captured. It's now possible to change these hooks after the DragDropContext has been mounted. #49
• A Droppable's margins are now included in its droppable area #122

Fixes

• Fixed a bug which caused the app to end up in a broken state if a drag ends before dimensions have been collected #121

2.3.1

Improvements

It's now possible to place multiple Droppables within a shared scroll container. To achieve this we had to re-work the way that we capture a Droppable's dimensions, so that we can calculate its true visible bounds on the screen throughout a drag. This means we're now correctly taking into account window scroll, parent scroll, and internal scroll when working out a Droppable's area. Keep in mind that we still only support one scroll container + window scroll, though.

Here's a diagram we put together while we were working on this which captures some of the scenarios we cover:

2.3.0

Improvements

• Pressing the spacebar space while dragging with a mouse will now scroll the window #102 . We no longer prevent the browser default in this case. Previously we had the restriction in place to keep things simple. However, now that we correctly handle window scrolling there is no need to keep this restriction in place - so it has been removed! (caused the minor version bump ✨)
• Adding documentation about natural keyboard cross list movement #104
• Major refactor and simplification of the get-drag-impact function #92

Fixes

• Dropping a Draggable with a keyboard inside of a nested list will no longer cause the parent to lift #102. Thanks @seancurtis for raising this

2.2.4

Improvements

A more natural drop target

The Draggable you are over during a mouse drag is now based on the center position of the Draggable rather than the mouse selection point. #93 This brings it in line with the behaviour for Draggables moving out of the way of other Draggables in aDroppable. This is a more natural behaviour which bases the impact of a drag on the center of a Draggable. Technically I think this should have always been the case given the libraries emphasis on using the center of gravity for impacts - which is why this was listed as a patch release rather than a minor version. In hindsight I think this should have been a minor version. This one is a little grey. Anyway, enjoy!

Old behaviour	New behaviour

2.2.3

Fixes

• Droppable placeholders (DroppableProvided > placeholder) now take up the correct size #88. Previously they where considering margins in their size, but these margins where already accounted for elsewhere. Sadly the tests where not executing this use case - but they are now!

2.2.2

Fixes

• Margins for lists is now being calculated correctly #87. Thanks @jaredcrowe for the fix! This one snuck in at the last minute of #2 while trying to accommodate Droppables with internal padding.

Improvements

• Avoiding margin collapsing in stories commit

2.2.1

Fixes

• Moving to an empty list that has padding with a keyboard will now work correctly commit

This was already fixed for mouse movement before merging #2. However, the fix was not applied to keyboard movement.

2.2.0

Features

Moving between lists 🎉 #2 #3 #4

Horizontal	Vertical (more complex than a board)

• Adding support for moving between vertical and horizontal lists
• Works with both mouse and keyboard (thats right - keyboard!!)
• You can now utilise type and isDropDisabled to conditionally allow dropping on a Droppable.

This was a mammoth effort with 135 commits, 120 files changed and 176 new tests. But what is harder to see how much @jaredcrowe and I wrestled with creating a transition experience that is robust, flexible and natural. I will be writing a blog soon about some of the algorithms (a small collision engine) we came up to drive our beautiful and natural experience.

Thanks so much to @jaredcrowe for his significant contributions - both in code as well as discussions.

Changes

DraggableProvided placeholder

In order to support moving between lists a Droppable is now provided with a placeholder element (similar to that of a Draggable)

type DroppableProvided = {|
  innerRef: (?HTMLElement) => void,
+ placeholder: ?ReactElement,
|}

The Droppable placeholder needs to be inside the element that you are providing. This is not like Draggable where the placeholder needs to be a sibling of the provided element.

<Droppable droppableId="droppable-1">
  {(provided, snapshot) => (
    <div ref={provided.innerRef}>
      Good to go

+    {provided.placeholder}
    </div>
  )}
</Droppable>;

Is that all?

Yep! The original API was designed with this feature in mind so there is no other changes required. In order to allow Draggables to transition to different Droppables ensure that they share the same type prop (which can be the default type if no type prop is provided). That's, all! Enjoy!

Improvements

• Increased the React peer dependency range. #84 Thanks @pofigizm!
• Tones of refactoring and engineering health efforts all over the code base #2

Notes

This release brings to a close the first milestone for this project: Tree fort. Be sure to check out the other milestones to see what is coming next.

Thanks everyone!