Are lightning event synchronous or asynchronous?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
4
down vote
favorite
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?
lightning-components lightning event lightning-events
asked Sep 16 at 9:01
hellohowdoyoudo
936
add a comment |Â
up vote
4
down vote
favorite
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?
lightning-components lightning event lightning-events
asked Sep 16 at 9:01
hellohowdoyoudo
936
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 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).
– hellohowdoyoudo
Sep 16 at 9:49
add a comment |Â
up vote
4
down vote
favorite
up vote
4
down vote
favorite
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?
lightning-components lightning event lightning-events
asked Sep 16 at 9:01
hellohowdoyoudo
936
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?
lightning-components lightning event lightning-events
lightning-components lightning event lightning-events
asked Sep 16 at 9:01
hellohowdoyoudo
936
asked Sep 16 at 9:01
hellohowdoyoudo
936
edited Sep 16 at 9:45
asked Sep 16 at 9:01
hellohowdoyoudo
936
asked Sep 16 at 9:01
hellohowdoyoudo
936
asked Sep 16 at 9:01
hellohowdoyoudo
936
936
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 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).
– hellohowdoyoudo
Sep 16 at 9:49
add a comment |Â
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 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).
– hellohowdoyoudo
Sep 16 at 9:49
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 at 9:32
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 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).
– hellohowdoyoudo
Sep 16 at 9:49
@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 at 9:49
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
9
down vote
accepted
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.
answered Sep 16 at 10:53
sfdcfox
230k10177391
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
9
down vote
accepted
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.
answered Sep 16 at 10:53
sfdcfox
230k10177391
add a comment |Â
up vote
9
down vote
accepted
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.
answered Sep 16 at 10:53
sfdcfox
230k10177391
add a comment |Â
up vote
9
down vote
accepted
up vote
9
down vote
accepted
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.
answered Sep 16 at 10:53
sfdcfox
230k10177391
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.
answered Sep 16 at 10:53
sfdcfox
230k10177391
answered Sep 16 at 10:53
sfdcfox
230k10177391
answered Sep 16 at 10:53
sfdcfox
230k10177391
answered Sep 16 at 10:53
sfdcfox
230k10177391
230k10177391
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f232655%2fare-lightning-event-synchronous-or-asynchronous%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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 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).
– hellohowdoyoudo
Sep 16 at 9:49