Open Mischback opened 1 year ago
v1
/ the original implementation had its own drag'n'drop logic already implemented. Should be easily adaptable.
Nope
Most existing Drag'n'Drop libraries are pure JS implementations, that do not use HTML5's native drag'n'drop API.
This means they are required to implement lots of stuff and add quite some size to a bundle.
HTML5's native API requires the draggable elements to have an attribute draggable="true"
, which is basically fine. But as most of the elements that are meant to be draggable in Colorizer are dynamically created, this may cause some issues.
Possible solution: https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver
prepareItems(itemList)
=> prepareItems()
containerMutationCallback()
, prepareItems()
is now only used with getItems()
as input parameter, so the call to getItems()
can be internalized (again)createItem(item)
createItem()
is called in exactly one place, during prepareItems()
TDragToOrderDragResultCallback
(part of the external interface)DragToOrder
class
constructor
parametersevent.target
in the event handler methods (is it the dragged element or the element under the cursor?!)styleDropTargetHover
is not applied to the correct element! It should always go to another item with draggable="true"
, these are assumed to be the drop targets. As of now, it might go to child elements of that item.
During implementation of #40, the actual drag'n'drop operation is handled with SortableJS. However, this adds around 40 - 50kB to the bundle size, which is kind of not acceptable.
After finishing the initial implementation of the contrast grid, which should also allow drag'n'drop operations,
SortableJS
should be replaced, because I feel like the app is using just a minimal subset of its functions.v1
/ the original implementation had its own drag'n'drop logic already implemented. Should be easily adaptable.