8

This link should provide a lot of background information for my issue.

Basically the problem is with Application Events, and cached lightning components.

If your lightning component lives inside a tab, and the user navigates away from the tab, the component is saved in the cache. If the user navigates to the tab containing your component again, there are now two copies of the component in being run at the same time. Which for the most part should not have any issues, but it has lots of problems if you are utilizing APPLICATION events, as each event is consumed by every copy of the component and each copy also fires its own event.

This means 2 copies will incur 4 application event handling calls, and 3 copies will incur 9. Of course anything beyond 1 will be a bug so it doesn't matter anyways.

Until now, I have been using the workaround listed in the above link to prevent multiple Application Events from being called/handled.

When your component with the handler inits, register to some global spot like

$A.theOneTrueHandler = cmp;

Then everytime you handle the event check before doing your stuff

cmp === $A.theOneTrueHandler

However, with the rollout of LockerService and its protection of global objects from being altered, I can no longer utilize that workaround. I am wondering if anyone has found a solution which either kills cached components, or solves the application event propagation issue.

Improve this question
2
  • 1
    The issue is that you are trying to use a secured global entry point to an API ($A) that we do not want or allow you to mutate. Simply switching to decorating window with your expando should work fine and now with Locker it's a safe thing to do since this is your own copy of SecureWindow (nobody can mess with it outside of your namespace and unlike traditional global scope you can't trounce other namespaces).
    – Doug Chasman
    Jan 24, 2017 at 14:28
  • I had similar issue and this question helped me with clues to my solution, just in case if anyone lands up on this question, they might even get help from my question hence adding link here: salesforce.stackexchange.com/questions/305146/…
    – JPReddy
    May 8, 2020 at 7:49

1 Answer 1

Reset to default
4

The workaround I did to solve this issue is to destroy the component byself when navigation happens.

  1. Register an listener for aura:locationChange event.

  2. Once the navigation happens, action tied to the listener get called which destroys the component using component.destroy().

Look at this answer for more detail.

Improve this answer
3
  • did this work for all location change events? Because it seems that location change events are flakey and don't respond to all navigations . salesforce.stackexchange.com/questions/211558/…
    – Bryan
    Jul 4, 2018 at 14:42
  • @Bryan Got a response on this issue from the Lightning Team. I have posted the response as the answer to your above question, please check it out.
    – Praveen
    Jul 5, 2018 at 17:04
  • Be very careful with destroy component, you might not fire any events when you come back to this component as it is already destroyed. Make sure you understand its implications before using it.
    – JPReddy
    May 8, 2020 at 7:51

You must log in to answer this question.

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