Are lightning event synchronous or asynchronous?


     <aura:handler name="event1" event="zced:TypeDoesNotMatter"
     <aura:handler name="event2" event="zced:TypeDoesNotMatter"


     <aura:registerEvent name="event1" type="zced:TypeDoesNotMatter"/>
     <aura:registerEvent name="event2" type="zced:TypeDoesNotMatter"/>

controller of componen2:

const event1 = component.getEvent("event1").fire();
const event2 = component.getEvent("event2").fire();

In other words is it guaranteed by the framework that after calling controller of componen2 the function event1Function in component1`s controller will be called before event2Function in component1`s controller?

  • Can you refine your question? Your example of two handler methods for 1 event is more about handler execution order, and needing to know that could be avoided by calling 1 method that calls the other 2 methods in a specific order. On synchronous/asynchronous, my understanding is that execution order is well defined if all the components are already loaded. But if a component has to be fetched from the server, then the execution in that component has to be done later. Making correct behavior dependent on what components are loaded would be a fragile approach. But I may be wrong.
    – Keith C
    Commented Sep 16, 2018 at 9:32
  • @KeithC, the main advantage of using event for me is reusability. I implement some logic which happens on event and do not have to worry about it, just call it whenever I need. So, now I have two events which perform some operations. I need to be sure that the first event will be executed before the second. For the sake of decomposition and as a result reusability I can not put those two methods in one handler (for example, sometimes I need only one of them). Commented Sep 16, 2018 at 9:49

1 Answer 1


Are lightning event synchronous or asynchronous?



When fire() is called, the event is placed in to a queue for later execution.


Until canceled or completed, only one event will be in the "executing" phase at any given time.


Once an event has been fully handled, the event queue is checked and the next event is fired. This continues until the queue is empty, at which point the life cycle concludes with a render/reRender cycle.


JavaScript can only run one thread at a time (ignoring things like ServiceWorker), which means that once the Aura life cycle starts, it will conclude without interruption from external events. It will process all managed events in the order they're placed in the queue, and nothing will change that order.

Not Guaranteed

However, even though the entire system design is essentially guaranteed that events will happen in the order you expect them to, there is no written guarantee that this is the case, or will continue to be the case in the future. You could choose to rely on this behavior, but if the nature of either JavaScript or Aura changes, you might find that your events no longer work as you expect, or randomly fail because of race conditions.

I would say that the risk is minimal, but non-zero. I wouldn't rely on this design in my own code, but I also wouldn't stop people from using it. If it's the pattern that makes the most sense, then you can certainly go for it. I'd probably use a slightly larger event that includes handling information, and let the handler decide if event1Function or event2Function would be called based on parameters.

You must log in to answer this question.

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