-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
Drag aggregations to sort instead of having up/down arrows. #6566
Drag aggregations to sort instead of having up/down arrows. #6566
Conversation
@bevacqua you might want to test this against the |
@@ -5,7 +5,7 @@ | |||
|
|||
<div class="vis-editor-agg-group" ng-class="groupName"> | |||
<!-- wrapper needed for nesting-indicator --> | |||
<div ng-repeat="agg in group" class="vis-editor-agg-wrapper"> | |||
<div class="vis-editor-agg-wrapper" ng-repeat="agg in group"> |
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.
Is there a reason for this change? In general we try to keep the angular attributes first, though it's not formalized in the style guide or even used in this file 🎈
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.
Ah, I guess I'm just used to having them the other way around. FWIW the <div
right above this line is consistent with the change I had made. But good to know
I like how succinct the changes here are, but I'd love to see it rely a bit less on direct dom access. To illustrate my point, this is how I'd probably organize this:
|
|
||
const drake = dragula({ | ||
containers: $('.vis-editor-agg-group', $el).toArray(), | ||
moves(el, source, 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.
Are you not a fan of making the whole container draggable? I tried removing this function to see what would happen and was pleasantly surprised how "sloppy" I could get with my mouse and still get the job done.
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.
Well. Affordances. I'd be fine with that if and only if we could clearly convey that aggregations are draggable. Right now the button combined with the cursor when its hovered over makes that pretty clear.
Oh, also, reordering the aggs doesn't seem to dirty the aggregation state. Rather than editing the |
@bevacqua is this still in progress? |
@rashidkpc Yup! Just got back from a couple of holidays last week, getting back up to speed! Same goes for #6543 |
scope: true, | ||
controllerAs: 'draggableItemCtrl', | ||
controller ($scope, $attrs, $parse) { | ||
$scope.draggableItemCtrl.getItem = () => $parse($attrs.draggableItem)($scope); |
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.
$scope.draggableItemCtrl === this
cac4752
to
bdf321b
Compare
jenkins, test it |
1 similar comment
jenkins, test it |
Not sure why the tests are failing here. |
jenkins, test it |
@epixa Thanks to Lee's thorough help I was able to identify the culprit. Tests are now passing. |
expect($scope.drake.canMove(item[0])).to.eql(false); | ||
}); | ||
|
||
it('shouldn\'t be able to move [draggable-item] if it has a handle', function () { |
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.
In the future, just use string templates instead of escaping the single quote. Or should not
.
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.
Right. Bad habit!
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.
Don't bother changing it. That was just a note for posterity's sake.
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.
👌
I only found one issue (in Firefox, if that matters). If you're dragging the bottom bucket or trying to drag a bucket below the bottom bucket, the "Add sub-buckets" button appears to piggy back on the dragging behavior. It doesn't actually end up moving, but the effect while you're dragging makes it look like it will. Worse, you actually need to drag the bucket below the button itself in order to move it to the end: |
LGTM |
## Summary `eui@74.0.2` ⏩ `eui@75.0.0` ___ ## [`75.0.0`](https://github.com/elastic/eui/tree/v75.0.0) - `EuiFlyout`s now automatically shard all fixed `EuiHeader`s on the page. This means that interactions (mouse & keyboard) with items inside `EuiHeader`s when flyouts are open will no longer trigger focus fighting ([#6566](elastic/eui#6566)) - `EuiFlyout`s now read out detailed screen reader dialog instructions and hints on open ([#6566](elastic/eui#6566)) **Bug fixes** - Fixed `EuiSelectable` options with incorrect `aria-posinset` indices when rendered with group labels not at the start of the array ([#6571](elastic/eui#6571)) - Fixed a bug with `EuiSearchBar` where filters with `multiSelect: false` were not able to select a new option when an option was already selected ([#6577](elastic/eui#6577)) **Breaking changes** - Removed the ability to customize the `role` prop of `EuiFlyout`s. `EuiFlyout`s should always be dialog roles for screen reader consistency. ([#6566](elastic/eui#6566)) - Removed `closeButtonAriaLabel` prop from `EuiFlyout` - use `closeButtonProps['aria-label']` instead ([#6566](elastic/eui#6566)) --------- Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary `eui@74.0.2` ⏩ `eui@75.0.0` ___ ## [`75.0.0`](https://github.com/elastic/eui/tree/v75.0.0) - `EuiFlyout`s now automatically shard all fixed `EuiHeader`s on the page. This means that interactions (mouse & keyboard) with items inside `EuiHeader`s when flyouts are open will no longer trigger focus fighting ([elastic#6566](elastic/eui#6566)) - `EuiFlyout`s now read out detailed screen reader dialog instructions and hints on open ([elastic#6566](elastic/eui#6566)) **Bug fixes** - Fixed `EuiSelectable` options with incorrect `aria-posinset` indices when rendered with group labels not at the start of the array ([elastic#6571](elastic/eui#6571)) - Fixed a bug with `EuiSearchBar` where filters with `multiSelect: false` were not able to select a new option when an option was already selected ([elastic#6577](elastic/eui#6577)) **Breaking changes** - Removed the ability to customize the `role` prop of `EuiFlyout`s. `EuiFlyout`s should always be dialog roles for screen reader consistency. ([elastic#6566](elastic/eui#6566)) - Removed `closeButtonAriaLabel` prop from `EuiFlyout` - use `closeButtonProps['aria-label']` instead ([elastic#6566](elastic/eui#6566)) --------- Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Implements #5563.
$state
persistance