I am new to lightning experience and components. I have been through some blogs and code that guide through the basics, but other than that I haven't had much hands-on experience.

My question is:

When to use component events vs application events? If I have nested components (parent & child) and if the events are of type Component, will the parent be able to handle events fired from child, and vice versa?

Also, I've noticed there are two ways to get an instance of an event (say TestEvent) -




Is there any difference between the both? What do "$A" & "e" in the second form, represent?

Thanks in advance for your reply!

  • 2
    Here's another blog that talks about pushing Component level events to their limits. I've found Component Events to be much snappier and the docs recommend using Component events whenever possible. Aug 17, 2016 at 14:33

3 Answers 3


Component events: to talk to a parent using the capture and bubbling mechanism, like with DOM events. Usually, one component is interested by the event, like an event aggregator.

Application events: to broadcast to other components and not exclusively ancestors. Applications events can talk to many components that can be interested by the event. The broadcast can be boxed to an area of the DOM (everything below a DIV for example).

About $A.getEvt() & cmp.getEvent():

Events have been seriously revamped, and the distinction between Component and Application events has been reduced. However, this rework has not yet been translated into an updated API.

I need to remove references to the $A.getEvt() and cmp.getEvent() API because we are still working on a new version of the API. My apologies for the confusion.

About value providers:

Lightning has various value providers: "v" for attributes, "c" for controller, and "e" for events.

Application Event API:

Those are obtained from the global (hence $A.get()) event value provider:

var evt = $A.get("e.myNamespace:myEvent");

Component Event API:

Component must reference events by name, much like an aura:id, and retrieve them from its component (hence cmp.get()) value provider:

var evt = cmp.get("e.myEvent");

You would then declare myEvent on the component as:

<aura:registerEvent name="myEvent" type="namespace:eventName"/>

Why dow have this API? Declaring events on a component allows other components to call controller methods. You had to declare a handler:

<aura:handler name="myEvent" action="{!c.myEventHandler}"/>

That allowed you to call myEventHandler from another component and respect the interface:

  • Thank you for your reply. So if I use $A.getEvt("namespace:eventName"); I don't need to register the event using <aura:registerEvent>?
    – James
    Aug 18, 2016 at 21:50
  • See my comments. My apologies, we are not exposing $A.getEvt() in LockerService.
    – JF Paradis
    Aug 24, 2016 at 18:39
  • Ah! Thanks for the clarification. If there's a go-to/reference link for the current and future API documentation, that would be helpful. :)
    – James
    Aug 24, 2016 at 19:27
  • I don't see "The broadcast can be boxed to an area of the DOM (everything below a DIV for example)." mentioned in the current document. Can you point me to such documentation?
    – Keith C
    Dec 16, 2017 at 10:00
  • I'm trying to solve this problem salesforce.stackexchange.com/questions/202081/….
    – Keith C
    Dec 16, 2017 at 11:41

Component Events follow Event Bubbling Mechanism .

Lets understand with an example component from salesforce docs

    <c:eventBubblingGrandchild />

In the above example lets say eventBubblingGrandchild component fired an event ,the event then bubbles up and can be handled by a component in the containment hierarchy that receives the bubbled event.

The syntax to handle this is


A containment hierarchy in this case is not c:eventBubblingChild instead it is c:eventBubblingParent .The event is not handled by c:eventBubblingChild as c:eventBubblingChild is in the markup for c:eventBubblingParent but it's not a facet value provider as it's not the outermost component in that markup.

Application events can be handled by any component and does not depend on hierarchy .

The syntax to handle for this is


Now to answer your question on parent to child as you can see you cannot use component events to fire from parent and handle in child while vise versa is true but the event bubbles only to the top containment .

  • Thank you for your reply, and the documentation on Event Bubbling Mechanism. It helped me understand things better. Could I still use $A.get("e.c:TestEvent") if the event is of type component, or is it a standard to just use component.getEvent for events of type component, and $A.get for application type components?
    – James
    Aug 18, 2016 at 21:55

Component Events : -

A component event is fired from an instance of a component. A component event can be handled by the component that fired the event or by a component in the containment hierarchy that receives the event.

Application Events : -

Application events follow a traditional publish-subscribe model. An application event is fired from an instance of a component. All components that provide a handler for the event are notified.

Both the events are registered in same manner, only difference lies in the way we get instance of that event to set param and the way we handle them.

Getting an instance of an Event : -

  1. Application Event : -

    var event = $A.get("e.nameSpace:EventName");

  2. Component Event : -

    var event = component.getEvent("EventName");

Handling the Events :-

  1. Application Event : -

    <aura:handler event="c:EventName" action="!c.handleApplicationEvent}" />

    It does not have the name attribute, which the component event has which basically is the same name we registered with.

  2. Component Event :

    <aura:handler name="reisteredEventName" event="c:EventName" action="{!c.callInChild}" />

    It has the name attribute which is the same name we registered the event in the Child Component.

You must log in to answer this question.

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