7

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.

  • 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 '17 at 14:28
3

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.

  • 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 '18 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 '18 at 17:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.