-
Notifications
You must be signed in to change notification settings - Fork 11
Conversation
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.
Had some comments but looking good
* Emmitted when the the handle is activated and the up or down arrow key is pressed. | ||
* @event calciteHandleNudge | ||
*/ | ||
@Event() calciteHandleNudge: EventEmitter; |
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.
Maybe call this calciteHandleMove
?
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.
hmmm...you're not really moving the handle right you're moving the parent. @franco thoughts? I'm def open to renaming tho its a meh name.
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.
Maybe we don't need this event and the keydown logic can just be added on the parent?
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 we do keep the event(s), let's make it based on whether it should be moved ahead or behind in the list instead of using direction like up/down/left/right.
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.
It's cleaner with the event, otherwise the event handler gets a bit messy when trying to find the handler in the composedPath.
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.
Leaving as up/down for now. We can add other directions in the future.
|
||
render() { | ||
return ( | ||
<button |
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.
Does it not need a host
?
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.
doesn't seem necessary. The :host selector is still applied to the tag. I think you only need it if you either need the parent wrapper or if you need to modify its attributes.
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.
Looking good
* Emmitted when the the handle is activated and the up or down arrow key is pressed. | ||
* @event calciteHandleNudge | ||
*/ | ||
@Event() calciteHandleNudge: EventEmitter; |
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 we do keep the event(s), let's make it based on whether it should be moved ahead or behind in the list instead of using direction like up/down/left/right.
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.
comments
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.
👍
/** | ||
* The class on the handle elements. | ||
*/ | ||
@Prop() handleSelector = ".handle"; |
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.
So is the .handle
going into the shadowDom and the drag and drop supports it? Just wondering why it isn't just calcite-handle
.
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.
the host can't receive focus, its basically a div. The button is the focus item and the cornerstone of the handle functionality. When using the keyboard, when sortable sorts the items, the parent of the handle will be removed from the dom and re-inserted. This causes it to lose focus so we have to re-apply focus. That focus needs to go on the button, not the host.
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.
@pr3tori4n does Sortable find the .handle
in the shadowDOM? Is that how this works?
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.
fixme: Lets change this to calcite-handle
by default with the setFocus()
method.
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.
Lets change the handle to have a setFocus()
method similar to the calcite-action to handle focusing internally.
this.items = Array.from(this.el.children); | ||
|
||
event.detail.handle.activated = true; | ||
event.detail.handle.shadowRoot.querySelector(this.handleSelector).focus(); |
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.
fixme: I think we should add a setFocus()
method on the handle instead of going through the shadowRoot. We already do this for the calcite-action
and calcite-panel
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.
@pr3tori4n this wouldn't work in Edge anyway
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.
It should now that Edge is on Chromium shouldn't 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.
It should now that Edge is on Chromium shouldn't it?
We should support older edge users regardless.
/** | ||
* The class on the handle elements. | ||
*/ | ||
@Prop() handleSelector = ".handle"; |
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.
fixme: Lets change this to calcite-handle
by default with the setFocus()
method.
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.
Just some questions on typings.
|
||
@State() handleActivated = false; | ||
|
||
items: Element[] = []; |
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.
question: should this be HTMLElement? since its coming chiildren of HTMLElement.
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.
changing this causes a TS error on lines this.items = Array.from(this.el.children);
Related Issue: #483
Summary
calcite-sortable-list
component, which can accept a list of any DOM nodes that can be sorted, so long as they have a handle with the same class as what's provided to the list (defaults to .handle).calcite-handle
component, which is a button that has the drag icon. This element has an activated prop which toggles based on if it's selected via keyboard, and fires a custom event when the up and down arrow keys are pressed when focused on the element.drag-handle
boolean prop, which adds acalcite-handle
to the heading area when true. False by default.