Skip to content
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

Merged
merged 15 commits into from May 27, 2016

Conversation

bevacqua
Copy link
Contributor

Implements #5563.

  • Added drag and drop replacing up/down
  • Added enable/disable
    • Support for save $state persistance

screen shot 2016-03-29 at 20 30 01

screen shot 2016-03-29 at 20 30 10

@rashidkpc
Copy link
Contributor

@bevacqua you might want to test this against the feature/design branch. The changes are pretty minimal, but you should probably check it.

@@ -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">
Copy link
Contributor

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 🎈

Copy link
Contributor Author

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

@spalger
Copy link
Contributor

spalger commented Mar 19, 2016

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:

  • create a directive for both the sortable container and sortable item
  • in container directive
    • expose a controller to the items, with a linkAgg(agg, element) method
    • instantiate dragula, wire up the events and such, use the controllers element by injecting $element
    • expose the dragging variable on $scope, so that the template can hide the add button when dragging starts
  • in item directive
    • require the container directive
    • in the link function call linkAgg() with own agg and element
  • in linkAgg(agg, element)
    • maps agg instances to elements (maybe vise versa?) using a WeakMap
  • in the handlers for drag/drop/etc.
    • use the elementToAgg map to find the agg for related elements


const drake = dragula({
containers: $('.vis-editor-agg-group', $el).toArray(),
moves(el, source, handle) {
Copy link
Contributor

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.

Copy link
Contributor Author

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.

@spalger spalger assigned bevacqua and unassigned spalger Mar 19, 2016
@spalger
Copy link
Contributor

spalger commented Mar 19, 2016

Oh, also, reordering the aggs doesn't seem to dirty the aggregation state. Rather than editing the $scope.group you need to update the order of $scope.vis.aggs

@rashidkpc
Copy link
Contributor

@bevacqua is this still in progress?

@bevacqua
Copy link
Contributor Author

@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);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

$scope.draggableItemCtrl === this

@bevacqua bevacqua assigned spalger and unassigned bevacqua Mar 28, 2016
@bevacqua bevacqua force-pushed the feature/sort-dimensions-dragging branch from cac4752 to bdf321b Compare March 29, 2016 16:22
@bevacqua
Copy link
Contributor Author

jenkins, test it

1 similar comment
@spalger
Copy link
Contributor

spalger commented Mar 30, 2016

jenkins, test it

@spalger spalger assigned bevacqua and unassigned spalger Apr 5, 2016
@spalger
Copy link
Contributor

spalger commented Apr 5, 2016

Not sure why the tests are failing here.

@epixa
Copy link
Contributor

epixa commented May 12, 2016

jenkins, test it

@bevacqua bevacqua assigned epixa and unassigned bevacqua May 12, 2016
@bevacqua
Copy link
Contributor Author

@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 () {
Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right. Bad habit!

Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👌

@epixa
Copy link
Contributor

epixa commented May 18, 2016

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:

drag

@epixa epixa assigned bevacqua and unassigned epixa May 18, 2016
@bevacqua bevacqua assigned epixa and unassigned bevacqua May 20, 2016
@bevacqua
Copy link
Contributor Author

@epixa The issue you mentioned should be fixed in 431ba4c

@epixa
Copy link
Contributor

epixa commented May 27, 2016

LGTM

@bevacqua bevacqua merged commit 1cf2979 into elastic:master May 27, 2016
@epixa epixa added v5.0.0 and removed v5.0.0 labels Jun 28, 2016
@BigFunger BigFunger mentioned this pull request Sep 22, 2016
1Copenut added a commit that referenced this pull request Feb 14, 2023
## 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>
justinkambic pushed a commit to justinkambic/kibana that referenced this pull request Feb 23, 2023
## 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants