-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(dragging): Create (new) IDragger
and IDraggable
interfaces
#7953
Conversation
Rename core/interfaces/i_draggable.ts to core/interfaces/i_draggable.old.ts to make room for new IDraggable. Do not rename actual interface as it's not yet clear that it will be necessary for both to coexist as imports in the same file.
1e5615b
to
b1f15ad
Compare
* be supplied as an alternative to providing a PointerEvent for | ||
* programatic drags. | ||
*/ | ||
drag(newLoc: Coordinate, e?: PointerEvent): void; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you want to structure the method signature like this, should the event be non-optional? Otherwise you basically have three function signatures:
drag(newLoc: Coordinate);
drag(newLoc: Coordinate, e: PointerEvent);
drag(newLoc: Coordinate, target: IDragTarget);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That looks like what I intended.
If e: PointerEvent
is non-optional then target
would need to be nullable (or otherwise optional) to cover the case where you are doing a programmatic drag (no PointerEvent
, unless maybe you synthesise one) and you don't happen to be over a drag target.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make more sense to explicitly provide the three function signatures then? Small preference from me, but not a big enough deal to block. I'm going to switch this review back to approve.
core/interfaces/i_draggable.ts
Outdated
* @param e PointerEvent that continued the drag; could be used to | ||
* look up any IDragTarget the pointer is over, check modifier | ||
* keys, etc. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If provided, they /should/ look up the drag target and deal with it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point.
b1f15ad
to
981a5e0
Compare
The basics
The details
Resolves
Fixes #7838.
Proposed Changes
core/interfaces/i_draggable.ts
tocore/interfaces/i_draggable.old.ts
and update imports of it.IDragable
interface incore/interfaces/i_draggable.ts
.IDragger
interface incore/interfaces/i_dragger.ts
.Reason for Changes
API changes to support custom dragging.
Test Coverage
Passes
npm test
.Additional Information
I wasn't sure about whether to make the
target
parameter ofIDraggable
'sdrag
method optional or nullable. Opinions welcome.I wasn't clear whether the
totalDelta
parameter ofIDragger
'sonDrag
method was intended to be cumulative or not, but I supposed it was given that the non-cumulative drag distance is presumably available via the (non-optional)PointerEvent
parameter. (It's slightly unclear to me why we are making the gesture responsible for keeping track of the cumulative drag, but perhaps it has reasons to do so already.)