This release is aimed at improving overall ease of use
Improvements
Moving to long press only for starting a touch drag 👇📱🕑🎉 #176
A Draggable component will no longer stop a user from scrolling the page natively on their touch device. This means that you can have a list that is both reorderable as well as scrollable natively.
When we originally built touch dragging we wanted a long press only solution #165. We have to opt in or out of native scrolling on the first touchmove. We found that a touchmove always would fire instantly when selecting an item. Given that we did not know if the user was trying to scroll we had to opt out of native scrolling even if the user did not perform a long press. However, this finding proved to be inaccurate and indeed on actual devices a touchmove is not always fired instantly (unless the user moves their finger). This has allowed us to move back to the original intention of supporting only long press for dragging. This strikes the right balance between enabling drag and drop without interfering too heavily with standard browser interactions. You can read more about it on the issue #176 as well as in the docs.
A big thanks to @humphreybc and @bradleyayers for challenging our assumptions and pressing for a beautiful user experience.
This resulted in a minor version change
Better default for interactive elements #190
Previously we suggest monkey patching event handlers to block dragging on interactive elements - button, input and so on. This was a simple technique based on the thinking that not many people would want interactive elements within their drag handles anyway. However, this has been a constant source of issues for the repo.
#189, #185, #149, #110, #199 (there are probably others)
The default experience for interactive elements was broken and required the consumer to do some ugly monkey patching. We now provide a much more reasonable default which can be opted out of for increased control. We now block starting a drag on the following elements by default:
inputbuttontextareaselectoptionoptgroupvideoaudiocontenteditable(any elements that arecontenteditableor are within acontenteditablecontainer)
You can opt out of this behaviour by adding the disableInteractiveElementBlocking prop to a Draggable
This resulting in a breaking change 💥
Because this change in behaviour could break a consumer in some way depending on how they were relying on the previous behaviour we have decided to make this a breaking change 💥. Previously how interactive elements behaved by default was fairly broken and relied on monkey patching. Given we do not know exactly how people have monkey patched functions to get their desired behaviours we have decided to be cautions and label this as a breaking change. We want to avoid anybody bumping a minor version and having their applications break. For the vast majority of consumers nothing will need to be done, even if you where monkey patching. If you were previously monkey patching event handlers to get nested interactive elements working in a sane way you no longer need to and you should be safe to bump version without needing to change your existing code. Your monkey patching should not break anything it is now just redundant. If you where doing some conditional blocking of interactive elements then this will break you. You will need to opt out of the default by adding the
disableInteractiveElementBlockingprop to aDraggableand then your monkey patching will work as it did before.
Distribution bundles 🎁 #142
Thanks to the work of @vinifala we are now publishing react-beautiful-dnd as a stand alone bundle for consumption with other tools such as Clojurescript (see #142 for details) as well as consumption directly within the browser. We are now publishing the following files:
dist/react-beautiful-dnd.jsdist/react-beautiful-dnd.min.js(minified bundle)
If you are interested to know, the minified bundle is 34kb gzipped 👌
This resulted in a minor version change
More accurate placeholders #200
Placeholders now more accurately mimic the Draggable by replicating the margin configuration of the Draggable rather than setting its size inclusive of margins. This results in avoiding issues caused by margin collapsing when lifting a Draggable and moving it into other lists
This resulted in a patch version change
Notice: moving to React 16
It is worth calling out here that we are planning on moving to React 16 in early 2018. This will be listed as a breaking change and will result in the library no longer being compatible with React 15. You can read more information about it here: #202