Polymer: Events triggered inside a dom-if nested in a dom-repeat do not pass the current item to the event handler.

[beckula]

If I have a dom-repeat, and inside that dom-repeat I'm using a dom-if to show a button, and in that button I call an event handler for on-tap, the current item is not passed to the event handler.

However, if I use the hidden attribute instead, the current item is passed.

For example:

<template is="dom-repeat" items="{{myItems}}">
  <paper-menu-button vertical-align="bottom" horizontal-align="right">
      <paper-icon-button icon="more-vert" class="dropdown-trigger"></paper-icon-button>
      <paper-menu class="dropdown-content">
         <template is="dom-if" if="[[showRoleEditButton()]]">
            <!-- editRole function does NOT receive the item -->
            <paper-button on-tap="editRole">EDIT</paper-button>
          </template>
          <!-- approveRole function DOES receive the item -->
          <paper-button hidden="[[showApproveButton(item)]]" on-tap="approveRole">APPROVE</paper-button>
      </paper-menu>
  </paper-menu-button>
</template>

editRole(e) {
   // This is undefined
   e['model'].item
}

approveRole(e) {
  // This is defined
  e['model'].item
}

[samccone]

:+1:

[dfreedm]

Yep, confirmed with simple jsbin: http://jsbin.com/towase/edit?html,output

[voondo]

:+1:

[zoechi]

dup of #1919 ?

[beckula]

Somewhat. #1919 is specific to nested dom-repeats. In this case there's a dom-if nested inside a dom-repeat, although it appears to be a symptom of the same issue.

[hatpick]

:+1:

[kevinpschaaf]

Proposed solution: Make adding e.model to event in Templatizer optional, and have dom-if not do that since it is non-valued added in dom-if.

[TimvdLippe]

Working properly in Polymer 2 now: http://jsbin.com/norojocepi/edit?html,console,output

[iainjreid]

@TimvdLippe this was marked as a 1.x issue by @tjsavage, will there be a fix for this in Polymer 1?

[TimvdLippe]

We will only apply patches to 1.x if there are groundbreaking bugs in legacy applications. All other fixes will be targeted at Polymer 2. The 1.x issue label was used to track which issues were originally filed for Polymer 1. E.g. they had to be reviewed to see if they could be included into the new Polymer 2, which most of the issues did.

[iainjreid]

Okay, thank you for clearing that up. What's the stance on pull requests that resolve these sorts of issues?

[TimvdLippe]

We have been cleaning up PRs in the past few weeks to close unsalvageable or ancient PRs. Every 1.x PR is reviewed on a case-by-case basis. If it is not a very small fix or groundbreaking bug, we will probably close the PR.

If you can solve this issue with very minimal impact, we can of course take a look :smile: However, looking at the original issue, I think this was one of the fundamental issues in 1.x, which is why 2.x rewrote a lot of this logic.

[arthurevans]

@TimvdLippe I think doing what @kevinpschaaf suggested might be pretty easy; the challenge is doing so in a way that's forward-compatible with 2.0.

The Templatizer behavior's templatize method adds a 2nd argument in 2.0, so we can't just add an argument in 1.0. (the behavior isn't used by any of the built-in 2.0 elements, though, which go directly to the Templatize library, so usage of the behavior in 2.0 may be fairly light).

One could add a _doNotDecorateEvents flag to the instance. So dom-if could do:

this._doNotDecorateEvents = true;
this.templatize(this);

(here: https://github.com/Polymer/polymer/blob/1.x/src/lib/template/dom-if.html#L118)

And Templatizer could do:

if (!this.__doNotDecorateEvents) {
  archetype.listen = this._listenImpl;
}

(here: https://github.com/Polymer/polymer/blob/1.x/src/lib/template/templatizer.html#L125)

But I would want to run that by @kevinpschaaf for approval and then we'd need to write some tests... (And I haven't actually made these changes, so I can't guarantee they'd actually work :D )

[msi-matthew]

@arthurevans
I'm not precisely following your example, and am having this issue with Polymer 2.x.
Is there any new guidance on a workaround or fix?

My hacky workaround is to put a counter on the child element and not run the nested code.

count: { type: Number, value: 0 }

...

_onTap() {
  this.count++;
  if (this.count > 0) {
    // do something
  };
}