'target' field in 'event' argument passed into callback function for click/pointer events refers to first element instantiated

[hesamrabeti]

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.

<polymer-element name="x-custom-editor">
  <template>
   <paper-input></paper-input>
  </template>
</polymer-element>

document.addEventListener('pointerup', function(event) {
  console.log(event.target) // Prints parent DOM element
}

Contact me if you have any more questions.

[hesamrabeti]

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.

1. Traverse the shadow DOM and change all change-page-inducing tags to not cause a browser page change but to call a proprietary JavaScript function to change the current page.

2. Each change-page-inducing element handles it's own on-click logic. This can get messy very very fast.

3. Include a 'shadowTarget' field in the event passed to the callback function to indicate the specific element that was actually clicked/pointedto.

4. Create a 'view-changer' element that calls a global/dependency-injected function to signal the need to change the current view/url

Option 1 - Not bad but not the best solution, will probably end up as a library included in every SPA app
Option 2 - Not the best way forward due to the fact that you have to create special logic
Option 3 - This is my favorite solution but can potentially break down some tenants of modularity
Option 4 - Maybe non-browser (search engine) compatibility issues?

[sjmiles]

Check event.path for the complete path to the target.

On Thu, Jul 17, 2014 at 6:07 AM, hesamrabeti notifications@github.com
wrote:

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.

1. Traverse the shadow DOM and change all change-page-inducing tags to not
   cause a browser page change but to call a proprietary JavaScript function
   to change the current page.

2. Each change-page-inducing element handles it's own on-click logic. This
   can get messy very very fast.

3. Include a 'shadowTarget' field in the event passed to the callback
   function to indicate the specific element that was actually
   clicked/pointedto.

4. Create a 'view-changer' element that calls a global/dependency-injected
   function to signal the need to change the current view/url

Option 1 - Not bad but not the best solution, will probably end up as a
library included in every SPA app
Option 2 - Not the best way forward due to the fact that you have to
create special logic
Option 3 - This is my favorite solution but can potentially break down
some tenants of modularity
Option 4 - Maybe non-browser (search engine) compatibility issues?

—
Reply to this email directly or view it on GitHub
#641 (comment).

[hesamrabeti]

In my case it's always a NodeList with length == 0.

Is this typical behavior?

[hesamrabeti]

'atomos-view' is the top-level instantiated element.

[hesamrabeti]

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])
      }
    });

Here is a screenshot of the output:

[hesamrabeti]

I tried the following bit of code:

<atomos-card on-click="{{nodeClick}}">

  nodeClick: function(event) {
    console.log(event.path)
  },

It works perfectly:

0: div
1: div
2: atomos-card.node-card
3: div
4: document-fragment
5: atomos-view-directory#viewDirectory.core-selected
6: core-pages#pages.pages
7: document-fragment
8: atomos-view-node-explorer#viewNodeExplorer.core-selected
9: core-pages#pages.pages
10: document-fragment
11: atomos-view-project-explorer#viewProjectExplorer.view.core-selected
12: core-pages#pages.pages
13: document-fragment
14: atomos-view-explorer#viewExplorer.view.core-selected
15: core-pages#pages.pages
16: core-header-panel
17: document-fragment
18: atomos-view#atomos-view
19: body
20: html
21: document

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.

[sjmiles]

What browser and version are you using? event.path was not working
properly in Chrome 35, but was fixed in Chrome 36.

On Sun, Jul 20, 2014 at 12:04 PM, hesamrabeti notifications@github.com
wrote:

I tried the following bit of code:

nodeClick: function(event) {
console.log(event.path)
},

It works perfectly:

0: div
1: div
2: atomos-card.node-card
3: div
4: document-fragment
5: atomos-view-directory#viewDirectory.core-selected
6: core-pages#pages.pages
7: document-fragment
8: atomos-view-node-explorer#viewNodeExplorer.core-selected
9: core-pages#pages.pages
10: document-fragment
11: atomos-view-project-explorer#viewProjectExplorer.view.core-selected
12: core-pages#pages.pages
13: document-fragment
14: atomos-view-explorer#viewExplorer.view.core-selected
15: core-pages#pages.pages
16: core-header-panel
17: document-fragment
18: atomos-view#atomos-view
19: body
20: html
21: document

It seems like document.addEventListener('click', function(event){...})
acts differently than 'on-x' events on an element.

—
Reply to this email directly or view it on GitHub
#641 (comment).

[hesamrabeti]

Debian Version 35.0.1916.153. My evergreen seems to be a little less green than others.

[sorvell]

Chrome 36 and the ShadowDOM polyfill both properly support event.path.