-
Notifications
You must be signed in to change notification settings - Fork 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
'target' field in 'event' argument passed into callback function for click/pointer events refers to first element instantiated #641
Comments
This seems to be the correct way to behave based on the fact that the child elements are in the shadow DOM tree of the parent element and for modularity's sake children elements are considered a part of the parent element. However, this can create problems in certain situations. The old way of intercepting click events on 'a' tagged elements with an 'href' field in single-page applications no longer works. If you have modularized your app in such a way where the root index.html instantiates an 'app' custom element, all clicks events will now return the 'app' element. This returned element gives no real information on what element was clicked. There are 2 options for fixing this issue.
Option 1 - Not bad but not the best solution, will probably end up as a library included in every SPA app |
Check On Thu, Jul 17, 2014 at 6:07 AM, hesamrabeti [email protected]
|
'atomos-view' is the top-level instantiated element. |
Inspecting the console.log after-the-fact returns the zero-length array. An immediate print still does not give enough information. It stops at the first element instantiated instead of digging down to the deepest child. Here is the javascript code used to print: document.addEventListener('click', function(event) {
console.log()
console.log("EVENT: ", event)
console.log("EVENT PATH: ", event.path)
console.log("EVENT PATH.LENGTH: ", event.path.length)
console.log("PRINTING PATH ARRAY: ");
for(var i =0; i<event.path.length;i++) {
console.log(event.path[i])
}
}); |
I tried the following bit of code: <atomos-card on-click="{{nodeClick}}"> nodeClick: function(event) {
console.log(event.path)
}, It works perfectly: 0: div It seems like document.addEventListener(eventName, function(event){...}) acts differently than 'on-x' events on an element. Events passed into document.addEventListener() callbacks point to the first element instantiated in your 'index.html' (or equivalent) while events associated with a particular event in HTML (on-tap, on-click, etc.) return the full path. |
What browser and version are you using? On Sun, Jul 20, 2014 at 12:04 PM, hesamrabeti [email protected]
|
Debian Version 35.0.1916.153. My evergreen seems to be a little less green than others. |
Chrome 36 and the ShadowDOM polyfill both properly support event.path. |
If a custom element is made up of other elements, a mouse event on any of the children elements will initiate an event with the 'toElement' and 'target' fields pointing to the first parent element initiated in the root html file (before any imports).
For example, a 'pointerup' event on a 'paper-input' element inside a custom element named 'x-custom-editor' will pass in an 'event' object with the field 'target' set to the 'x-custom-editor' element instead of the 'paper-input' element.
Contact me if you have any more questions.
The text was updated successfully, but these errors were encountered: