Add Drag & drop component

[Lagicrus]

Summary 💡

Drag and drop components to reorder/reorganize them. Components that could use this could be either lists, grids, or chips.
Such as described on uxdesign]: https://uxdesign.cc/drag-and-drop-for-design-systems-8d40502eb26d and mentioned briefly on https://m2.material.io/design/interaction/gestures.html#types-of-gestures.

For lists, it could be done via an Icon that has that functionality whilst the rest of the ListItem does not, and you drag the "handle", not the list itself.
For more "boxy" elements, could work as a wrapper around the entire element OR as an icon in a corner that the user grabs.

Icon wise some ideas could be the drag handle, open_with, or toggle with CSS between the grab and grabbing cursor icon as outlined on MDN

https://web.archive.org/web/20200710063129/http://materialdesignadmin.com/sortable.html which I think uses https://github.com/SortableJS/Sortable

Examples 🌈

• Public benchmark: https://mui-org.notion.site/mui-x-Drag-drop-c4f756bde3d5434082cc9255153e7908
• Benchmark editale: https://www.notion.so/mui-org/mui-x-Drag-drop-c4f756bde3d5434082cc9255153e7908

Motivation 🔦

An easy way for developers to allow users to reorganize images, text, and such like which are grouped, alternatively as a quiz/ranking system of a 1 to 10 "Organise this list in the order in which you like these flavors of ice-cream".

Search keywords:

[TheHolyWaffle]

So ... basically react-beautiful-dnd? I don't think there would be any extra value if Material UI were to re-implement that behavior.

[Lagicrus]

So ... basically react-beautiful-dnd? I don't think there would be any extra value if Material UI were to re-implement that behaviour.

That is fair. I was unaware that existed.
I just felt, and do still feel that having it more baked into Material vs wrapping it in that module, allows for better/lower integration with Material components allowing more powerful and simpler integrations.

Additionally, in my opinion, if Material were to implement this enhancement themselves then it would be easier for developers to use, especially in the long run Vs just adding another dependency to the ever-growing list that is the package file.

Not to mention more likely to be shown in the documentation as a feature/way to do things, Vs an external package which would at best get a mention on the Related-Products page.

[oliviertassinari]

adding another dependency to the ever-growing list that is the package file

@Lagicrus I'm curious to hear more about this. What's issues have you faced with growing the list of dependencies in the package.json?

[Lagicrus]

adding another dependency to the ever-growing list that is the package file

@Lagicrus I'm curious to hear more about this. What's issues have you faced with growing the list of dependencies in the package.json?

Perhaps I worded this badly. But nothing wrong with Material UI.
What I was trying to explain was, with the way I see Material UI growing, you are more likely to make it yourself in some fashion Vs just adding an additional requirement for this 1 thing, which increases the bulk of installing, adds more sub-dependencies and chances for vulnerabilities.
Or at least, that is my understanding.

[re-thc]

react-beautiful-dnd doesn't have material-ui design and uses emotion instead. For the record there's also react-dnd.