apply position scaling when acceptwidgets is enabled #2578
Conversation
src/gridstack.ts
Outdated
| helper.appendChild(testEl); | ||
| const testElPosition = testEl.getBoundingClientRect(); | ||
| helper.removeChild(testEl); | ||
| const dragScale = { |
There was a problem hiding this comment.
you will need the offset as well, which makes now 3 copies of that code so it should be extracted into a util method instead.
There was a problem hiding this comment.
I moved some redundant logic for that to utils. I also now made it possible for elements dragged from outside to be scaled down when entering the grid, and scaled back up when they leave. Also their position were following the unscaled grid so I fixed that too.
I am not sure which offset you mean but I did adjust the offset for the outside item's helpers when they enter the grid.
Screen.Recording.2023-12-16.at.21.52.23.mov
adjusted position and scale of helper that is dragged from outside
src/dd-draggable.ts
Outdated
| @@ -79,6 +81,7 @@ export class DDDraggable extends DDBaseImplement implements HTMLElementExtendOpt | |||
| // get the element that is actually supposed to be dragged by | |||
| let handleName = option.handle.substring(1); | |||
| this.dragEl = el.classList.contains(handleName) ? el : el.querySelector(option.handle) || el; | |||
| this.transformReference = Utils.createTransformReferenceElement(); | |||
There was a problem hiding this comment.
is there a reason to save this as all ? we only need to calculate the scale/offset so no need to keep that element around (which then also needs to be freed
Have Utils.getValuesFromTransformedElement() create and delete it instead (internally)
There was a problem hiding this comment.
changed.
also it used to create a single instance of that div that could be reused for the next calls. i don't know what were the implications of creating this div and clearing it up on every single mousemove call. probably not much to worry about, so now it creates that element, gets the values, then deletes it.
on a side note, it turns out just calling parent.removeChild(transformReference) was not enough to delete the element: i had to call transformReference.remove() too
There was a problem hiding this comment.
| every single mousemove call
the scale/xform should not be called every move event - we know that info when we start/enter/leave - that should be fixed instead.
There was a problem hiding this comment.
dragTransform is only calculated in onStartMoving now
removed createTransformReferenceElement
| helper.style.transform = `scale(${1 / this.dragTransform.xScale},${1 / this.dragTransform.yScale})`; | ||
| // this makes it so that the helper is well positioned relative to the mouse after scaling | ||
| const helperRect = helper.getBoundingClientRect(); | ||
| helper.style.left = helperRect.x + (this.dragTransform.xScale - 1) * (event.clientX - helperRect.x) / this.dragTransform.xScale + 'px'; |
There was a problem hiding this comment.
not sure I understand the "slightly adjust its position" and code here - it s mapping exactly to the same relative point (vido seem that way). can't figure from the code right now
There was a problem hiding this comment.
Yes, that code is mapping to the same relative position after scaling. the mouse position relative to the element should be the same after scaling.
The "slightly" part refers to applying that extra code mentioned. Otherwise the relative position would look off after scaling.
There was a problem hiding this comment.
@Amdoun @adumesny These lines (setting left and top on helper) don't work well when the draggable has different appendTo than body (defined in setupDragIn), and when this appendTo element has top/left greater than 0.
Helper element receives mouse positions + offset of the appendTo element, placing it wrong.
There was a problem hiding this comment.
@creage, please file a bug with a test case showing the issue. I'll have to remind myself why we have appendTo:element to start with (likely historical jquery UI option) as I'm not sure the use case - if you can comment on that as well.
supporting too many options makes the lib complicated/briddle.
There was a problem hiding this comment.
@adumesny Well, we don't want to add draggable helper to the body, but we want them to stick under some parent container - this way we can adjust styling of such helpers easily, and less pollute to the global body scope.
Like, a Dialog that shows a GridStack with some items we can drag to the grid. All styling is defined within the Dialog component, which we can use in different areas in our app.
So, this option is quite useful - please don't remove it.
There was a problem hiding this comment.
| All styling is defined within the Dialog component
ok makes sense. but then aren't items clipped by the dialog when dragging around which is a little odd, even if you can only drop them in the grid of the dialog.
|
thanks for making these changes! |
Description
This fixes the issue i mentioned in #2575
Some of the code was added from 3c9bc4b to the event handler for dragging when acceptWidgets is set to true (which is located in gridstack.ts and not in dd-draggable.ts)
Checklist
yarn test) - I could not run the tests, can someone try it on my PR?