6

Greetings great people of the Salesforce Stackexchange,

We are having some trouble with Salesforce Locker Service update in the custom Lightning Components we're developing.

This works without Locker Service enabled, but breaks with it turned on.

Component:

<aura:iteration items="{!v.results}" var="result">
    <li class="slds-dropdown__item">
        <a onclick="{!c.select}" data-object="{!result.stringified}">{!result.Name}</a>
    </li>
</aura:iteration>

Controller:

select: function(component, event, helper){

    var valueObject = JSON.parse(event.target.getAttribute('data-object'));

    ...
}

With LockerService enabled, valueObject is null.

The event object looks like this: Preview of the event object in the console

event.target outputs as an empty object in the console: {}

We've tried event.getTarget(), event.getSource(), event.currentTarget and tons more examples we found throughout official Salesforce documentation, but without result.

How can we know what the user has clicked on with Locker Service?

Please liberate me from my ignorance. :)

6
  • Looks like you may want to use event.getSource().. developer.salesforce.com/docs/atlas.en-us.lightning.meta/… Nov 8, 2016 at 14:33
  • Thanks for responding! I read somewhere event.getSource is for built in lightening components only. When I use it I get "event.getSource is not a function". Nov 8, 2016 at 14:36
  • That is correct - there are 2 types of events being passed around in Lightning: Aura and DOM. For DOM events the code in the origin post looks correct. @joshuadelange what does event.target look like under locker? Can you also provide the results of eval'ing this in the js console: event + "" Nov 8, 2016 at 14:42
  • @DougChasman Thanks for your help! event.target outputs as an empty object in the console: {} Nov 8, 2016 at 14:49
  • 1
    I'm looking for: event + "" not event.target as I think the issue is further upstream Nov 8, 2016 at 14:56

2 Answers 2

8

I believe the issue here is at the intersection of aura:iteration and Locker resulting in a sort of custody battle over ownership of the resulting DOM. Opened bug W-3458193 to track this.

4
  • So, you mean that his component is losing the ownership of the DOM element because of the aura:iteration which kind of "steals" it ? Nov 8, 2016 at 15:10
  • 3
    Exactly - opened W-3458193 to track this and the Locker team is investigating now Nov 8, 2016 at 15:14
  • @DougChasman Thank you Doug! Were you able to hear anything back from them in the last week? Nov 16, 2016 at 14:55
  • @joshuadelange This seems to be fixed now. I have verified it in the Spring 17 release. Here's the component markup I used gist.github.com/anonymous/fcf2e7aee13d3d9f8cc2e125c5c9174b Please let us know if its still a problem. A git gist of your code showing sample data in v.results would be useful. Jan 12, 2017 at 0:10
3

Yes it's a big problem for now.

event.target, event.currentTarget are undefined because of locker service. I think they are suppose to fix it in a next release but for now you may need to create your own component "dropdownItem" and pass the data object as an attribute. Then after handling an onclick event triggered by your component you will be able to do event.getSource().get("v.dataObject").

If you need help with it I can give an example.

6
  • Ouch! Any ideas when Salesforce will have this fixed? Nov 8, 2016 at 14:47
  • Hold on a second Lucas - the post you linked to was about reaching into the internals of a component you do not own (lightning:buttonIcon) that has a design flaw in it that is being corrected. Not the case in the code above. This is not a bug in Locker - it is simply doing its job. The team that owns the lightning: namespace has been alerted, I opened a bug to track it etc and they said it would be fixed by now. Appears to have missed the boat for the current patch. Sigh. Nov 8, 2016 at 14:54
  • Oh okay @Doug. I agree with you my link is not a good example. So what do you mean about "simply doing its job" ? A component cannot access its own DOM elements anymore ? What would be your workaround for this ? Nov 8, 2016 at 15:02
  • 3
    The open bug for the team that owns the lightning: namespace is W-3453049 if you want to reference this in any communications with Salesforce. They are working on it but do not have an ETA yet. Nov 8, 2016 at 15:06
  • Thank you ! I deleted the link from my answer as it was not relevant. Nov 8, 2016 at 15:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .