Lightning Events: Detail Overview Part 2

In last post we study that in Lightning we have two types of Events. We study the Component Event. In this post we will continue and will cover the application 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.

Here is the sequence of application event propagation.

1. Event fired—An application event is fired. The component that fires the event is known as the source component.
2. Capture phase—The framework executes the capture phase from the application root to the source component until all components are traversed. Any handling event can stop propagation by calling stopPropagation() on the event.
3. Bubble phase—The framework executes the bubble phase from the source component to the application root until all components are traversed or stopPropagation() is called.
4. Default phase—The framework executes the default phase from the root node unless preventDefault() was called in the capture or bubble phases. If the event’s propagation wasn’t stopped in a previous phase, the root node defaults to the application root. If the event’s propagation was stopped in a previous phase, the root node is set to the component whose handler invoked event.stopPropagation().

Create Custom Application Events

We use type=”APPLICATION” in the <aura:event> tag for an application event. Events can contain attributes that can be setbefore the event is fired and read when the event is handled.

For example, this c:appEvent application event has one attribute with a name of message.

The component that fires an event can set the event’s data. To set the attribute values, call event.setParam() or event.setParams(). A parameter name set in the event must match the name attribute of an <aura:attribute> in the event. For example, if you fire c:appEvent, you could use:

event.setParam("message", "event message here");

The component that handles an event can retrieve the event data. To retrieve the attribute in this event, call event.getParam(“message”) in the handler’s client-side controller. This procedure of set and get attribute value in Event is same in both type of events.

Register an Event

A component may fire an application event by using <aura:registerEvent> in its markup. The name attribute is required but not used for application events. The name attribute is only relevant for component events. This example uses name=”appEvent” but the value isn’t used anywhere.

<aura:registerEvent name="appEvent" type="c:appEvent"/>

Fire an Event

We use $A.get("e.myNamespace:myAppEvent") in JavaScript to get an instance of the myAppEvent event in the myNamespace namespace.

Note: The syntax to get an instance of an application event is different than the syntax to get a component event, which is cmp.getEvent(“evtName“). Use fire() to fire the event.

var appEvent = $A.get("e.c:appEvent");
// Optional: set some data for the event (also known as event shape)  A parameter’s name must match the name attribute of one of the event’s  tags
//appEvent.setParams({ "myParam" : myValue });

appEvent.fire();

Handling Application Events

Use <aura:handler> in the markup of the handler component.

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

The event attribute specifies the event being handled. The format is namespace:eventName. The action attribute of <aura:handler> sets the client-side controller action to handle the event.

Note: The handler for an application event won’t work if you set the name attribute in <aura:handler>. Use the name attribute only when you’re handling component events. In this example, when the event is fired, the handleApplicationEvent client-side controller action is called.

Firing Lightning Events from Non-Lightning Code

We can fire Lightning events from JavaScript code outside a Lightning app. For example, our Lightning app might need to call out to some non-Lightning code, and then have that code communicate back to our Lightning app once it’s done.

For example, we could call external code that needs to log into another system and return some data to our Lightning app. Let’s call this event mynamespace:externalEvent. We’ll fire this event when our non-Lightning code is done by including this JavaScript in our non-Lightning code.We can use this process to call third part API and can do authentication calls.

var myExternalEvent;

if(window.opener.$A && (myExternalEvent = window.opener.$A.get("e.mynamespace:externalEvent"))) { myExternalEvent.setParams({isOauthed:true});

myExternalEvent.fire();

}

window.opener.$A.get() references the master window where our Lightning app is loaded.

Do you have anything to add, please let me know in comments section. Happy Programming 🙂