Are lightning event synchronous or asynchronous?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
3
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?










share|improve this question









New contributor




hellohowdoyoudo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.



















  • 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
    3 hours ago










  • @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
    2 hours ago
















up vote
3
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?










share|improve this question









New contributor




hellohowdoyoudo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.



















  • 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
    3 hours ago










  • @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
    2 hours ago












up vote
3
down vote

favorite









up vote
3
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?










share|improve this question









New contributor




hellohowdoyoudo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











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






share|improve this question









New contributor




hellohowdoyoudo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




hellohowdoyoudo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited 2 hours ago





















New contributor




hellohowdoyoudo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 3 hours ago









hellohowdoyoudo

824




824




New contributor




hellohowdoyoudo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





hellohowdoyoudo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






hellohowdoyoudo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











  • 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
    3 hours ago










  • @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
    2 hours ago
















  • 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
    3 hours ago










  • @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
    2 hours ago















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
3 hours ago




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
3 hours ago












@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
2 hours ago




@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
2 hours ago










1 Answer
1






active

oldest

votes

















up vote
2
down vote














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.






share|improve this answer




















    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "459"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );






    hellohowdoyoudo is a new contributor. Be nice, and check out our Code of Conduct.









     

    draft saved


    draft discarded


















    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






























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    2
    down vote














    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.






    share|improve this answer
























      up vote
      2
      down vote














      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.






      share|improve this answer






















        up vote
        2
        down vote










        up vote
        2
        down vote










        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.






        share|improve this answer













        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 1 hour ago









        sfdcfox

        227k10174389




        227k10174389




















            hellohowdoyoudo is a new contributor. Be nice, and check out our Code of Conduct.









             

            draft saved


            draft discarded


















            hellohowdoyoudo is a new contributor. Be nice, and check out our Code of Conduct.












            hellohowdoyoudo is a new contributor. Be nice, and check out our Code of Conduct.











            hellohowdoyoudo is a new contributor. Be nice, and check out our Code of Conduct.













             


            draft saved


            draft discarded














            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













































































            Comments

            Popular posts from this blog

            What does second last employer means? [closed]

            List of Gilmore Girls characters

            Confectionery