feat(swipe): allow accessing the original currentTarget

[gillyb]

When using the md-swipe-xxxx events, if you pass the $event and try to access $event.currentTarget you get null.
I am saving a reference to the original currentTarget and passing it on here, via $target object so we can use it.

Why do we even need currentTarget ?
Let's say you add the md-swipe-right directive to a div, and that div has a few child nodes. When the user swipes, the $event.target is the 'div' element the user swiped on, and not the 'div' element that we placed the md-swipe-right attribute on.
With other angular events (like 'on-click') we can get the div we want with $event.currentTarget, but this does't work for 'swipe' events.

This is basically what is stated here (but not for swipe events) :
https://stackoverflow.com/questions/29421360/angular-ng-click-event-passes-child-element-as-target
and here :
https://stackoverflow.com/questions/23107613/get-original-element-from-ng-click

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If your company signed a CLA, they designated a Point of Contact who decides which employees are authorized to participate. You may need to contact the Point of Contact for your company and ask to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the project maintainer to go/cla#troubleshoot.
• In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again.

[gillyb]

I signed it!

[googlebot]

CLAs look good, thanks!

[Splaktar]

ev doesn't appear to be defined at this point?

[Splaktar]

Thank you very much for your contribution!

In trying to better understand the requested changes, I have a couple of questions. Is there an existing issue that covers the problem being solved here in more detail? Is there a CodePen that demonstrates the issue?

[gillyb]

@Splaktar Thanks a lot for reviewing this! First, I fixed the scoping.
At first i fixed this bug locally, and I figured it was small enough to edit directly on github. Very amateur-ish mistake on my half!

I also created a code-pen to demonstrate the problem.
It's here :
https://codepen.io/gillyb/pen/EbeqXg?editors=1111

You will see there 2 directives, both with an inner element. On the first directive, when u click the inner element, it will print on the console, the element u clicked on, and also the parent element that the ng-click attribute was added to.
Something similar is there for swipe, which demonstrates the problem. When swiping on the inner element (or even the directive element), then $event.currentTarget is null, and throws an exception when i try to print it in the console.
This is exactly what my pull request fixes. :)

[Splaktar]

I see. The result is a little different on AngularJS 1.6.6. I created a CodePen for that. But either way, I do see how it fails.

It's unfortunate that the swipe component has no tests.

It might be helpful to add a small demo of this feature to the PR. However, what is the primary use case for this feature? I.e. how would it be possible to create a helpful and clear demo.

[gillyb]

I needed it in a very simple use-case actually - I have a list of items (in my case they were messages). On each 'item' I added the md-swipe directive, but the element had a few span elements with text on them, so one of the span elements on it was being returned from $event.target. I wanted to get the whole 'item' element to do some special DOM manipulation.

In many cases the right way to tackle this would be to use your 'model' and not reach the DOM element directly, although I still think the framework should allow this.

Where should I add a demo to the PR ? (The place I used it for isn't public, so I can't publish that).
Also, would you like me to add a note about it in the documentation?

[gillyb]

@Splaktar - Will this be merged?
Do you want me to add a note/example to the documentation?

[Splaktar]

OK, thank you for the explanation. That makes a lot of sense and seems like an extremely common use case.

Sorry for the delay. Can you please update the existing demo at https://github.com/angular/material/tree/master/src/components/swipe/demoBasicUsage to include a demonstration of this feature?

[Splaktar]

I think that adding the events onSwipeLeft($event, $target) to each call in the template and possibly just adding some logs of the output would be enough. I.e.

      $log.log('Event Target: ', ev.target);
      $log.log('Event Current Target: ', ev.currentTarget);
      $log.log('Original Current Target: ', target.current);

Example output from my testing:

Event Target:  <span class=​"no-select">​Swipe me to the left​</span>​
Event Current Target:  null
Original Current Target:  <div class=​"demo-swipe" md-swipe-left=​"onSwipeLeft($event, $target)​">​…​</div>​

The docs here should also be updated to show passing the params (i.e. <div md-swipe-left="onSwipeLeft($event, $target)">Swipe me left!</div>). Please also add a sentence briefly describing the $event and $target params in the @description of each directive's JSDoc.

[gillyb]

@Splaktar - I updated the pull request with proper documentation, and logs in the demo.

[Splaktar]

Excellent, this is looking good, thank you! I just need one update for consistency.

[Splaktar]

Please make this consistent with the others, I.e. this message under the Notes.

[gillyb]

My bad. Fixed this.
Thanks a lot - This is my first contribution to a big/popular open source repo, so very excited about that! 🎉

[gillyb]

@Splaktar Fixed the inconsistency issue. Thanks for catching that. :)

[Splaktar]

@gillyb thank you very much! I believe that only 1 step remains 😄 Please following these steps to squash your changes into a single commit.

[googlebot]

So there's good news and bad news.

👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there.

😕 The bad news is that it appears that one or more commits were authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request.

Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this State. It's up to you to confirm consent of the commit author(s) and merge this pull request when appropriate.

[gillyb]

@Splaktar so.. I took your advice and changed the commit history to squash the commits into one. Doing this too fast, led to me adding my changes to the last commit on the original branch (changing the branch's history).
So that's when the @googlebot removed the cla:yes tag and added the cla:no tag..
I took the original branch's history 'as is', added all my changes in a single commit, and the did push --force again so the history will be correct.

[gillyb]

Now all my changes are in a single commit, and I believe it's safe to merge.
Thanks for helping me out with this, and sorry for the mess now.. 💩

[Splaktar]

LGTM

[Splaktar]

Thank you very much for squashing the commits. Can you please amend your commit and force push just one more time? Please update the commit to follow the commit message guidelines. This will make sure that the change gets reported in our CHANGELOG correctly when a release happens.

I think that feat(swipe): allow accessing the original currentTarget would work.

[gillyb]

@Splaktar No problem, done 👍