Communicating with Events

The framework uses event-driven programming. You write handlers that respond to interface events as they occur. The events may or may not have been triggered by user interaction.

In the Aura Components programming model, events are fired from JavaScript controller actions. Events can contain attributes that can be set before the event is fired and read when the event is handled.

Events are declared by the aura:event tag in a .evt resource, and they can have one of two types: component or application.

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 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.

Always try to use a component event instead of an application event, if possible. Component events can only be handled by components above them in the containment hierarchy so their usage is more localized to the components that need to know about them. Application events are best used for something that should be handled at the application level, such as navigating to a specific record. Application events allow communication between components that are in separate parts of the application and have no direct containment relationship.

  • Actions and Events

    The framework uses events to communicate data between components. Events are usually triggered by a user action.

  • Handling Events with Client-Side Controllers

    A client-side controller handles events within a component. It’s a JavaScript resource that defines the functions for all of the component’s actions.

  • 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.

  • Event Handler Behavior for Active Components

    To prevent active event handlers on cached pages from causing problems, add a workaround to your code to check if the component is still visible. To avoid this scenario and the workaround, use Lightning message service instead to communicate across the DOM within a Lightning page. The default scope used by Lightning message service channels publishes only to active components.

  • Event Handling Lifecycle

  • Advanced Events Example

  • Firing Events from Non-Aura Code

    You can fire Aura events from JavaScript code outside an Aura app. For example, your Aura app might need to call out to some non-Aura code, and then have that code communicate back to your Aura app once it’s done.

  • Events Best Practices

    Here are some best practices for working with events.

  • Events Fired During the Rendering Lifecycle

    A component is instantiated, rendered, and rerendered during its lifecycle. A component rerenders only when there’s a programmatic or value change that requires a rerender. For example, if a browser event triggers an action that updates the component’s data, the component rerenders.

  • Events Handled in the Salesforce Mobile App and Lightning Experience

    The Salesforce mobile app and Lightning Experience handle some events, which you can fire in your Aura component.

  • System Events

    The framework fires several system events during its lifecycle.