[SalesForce] LockerService: Can’t access the DOM of a component on the same namespace

(Original question after the line)

After some further investigation, it looks like it becomes "SecureComponentRef" because the < th > is inside an aura:iteration, and the aura:iteration takes it into its own namespsace or something ('aura').
I understand why it does that programatically (everything is being passed as sort of an argument), but I don't understand why it would do that logically, as I should be allowed access to whatever I'm trying to design and is not part of the aura:iteration internal functionality.


So we've turned on LockerService a couple of weeks ago, expecting it to be in effect immediately, but came back from the weekend and now a piece of code isn't working.
Based on this post: component.find(…).getElement not working after Summer 16 release , it should've stopped working the moment I activated it had it been the case, but the issue is that both components are on the same namespace (allegedly):

Have an extensible abstract component with this code:

    sortRecords: function(component, event, records) {
      <...>
      headerElement = component.find('columnHeaders')[0].getElement();

Another component extends it and has this defined:

    <th aura:id="columnHeaders" class="{!globalId + '_columnHeaders' + ' slds-is-sortable' + ' slds-is-resizable'}" scope="col" onclick="{!c.sortRecords}" data-name="{!fieldName}">

And on that line of code I'm getting the "component.find(…)[0].getElement is not a function" error, because the < th > is now a SecureComponentRef (not sure what it was last week).
Is this not a purpose of having an abstract component? Any other best practice way I should design this?

Best Answer

This is a known issue with LockerService. Even though your element is inside an iteration, it should still return a SecureComponent instead of a SecureComponentRef as you've discovered. We're actively working on a fix. You can open a case to track and tell them to link to W-3206803.

Related Topic