Drag aggregations to sort instead of having up/down arrows.#6566
Drag aggregations to sort instead of having up/down arrows.#6566bevacqua merged 15 commits intoelastic:masterfrom
Conversation
|
@bevacqua you might want to test this against the |
There was a problem hiding this comment.
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.
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:
|
There was a problem hiding this comment.
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.
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 |
There was a problem hiding this comment.
$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.
In the future, just use string templates instead of escaping the single quote. Or should not.
There was a problem hiding this comment.
Don't bother changing it. That was just a note for posterity's sake.
|
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.
$statepersistance