Are lightning event synchronous or asynchronous?
Are lightning event synchronous or asynchronous?
Are lightning event synchronous or asynchronous?
component1:
<aura:component>
<aura:handler name="event1" event="zced:TypeDoesNotMatter"
action="!c.event1Function"/>
<aura:handler name="event2" event="zced:TypeDoesNotMatter"
action="!c.event2Function"/>
<component2/>
</aura:component>
component2:
<aura:component>
<aura:registerEvent name="event1" type="zced:TypeDoesNotMatter"/>
<aura:registerEvent name="event2" type="zced:TypeDoesNotMatter"/>
</aura:component>
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?
@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).
– hellohowdoyoudo
Sep 16 '18 at 9:49
1 Answer
1
Are lightning event synchronous or asynchronous?
Yes.
Asynchronous
When fire() is called, the event is placed in to a queue for later execution.
Atomic
Until canceled or completed, only one event will be in the "executing" phase at any given time.
Synchronous
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.
Single-Threaded
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.
Thanks for contributing an answer to Salesforce Stack Exchange!
But avoid …
To learn more, see our tips on writing great answers.
Required, but never shown
Required, but never shown
By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy
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
Sep 16 '18 at 9:32