This series introduces you to the Lightning Component Framework through a free online course by Salesforce University combined with a six part blog series written by Don Robins, a Salesforce MVP, Certified Advanced Developer and Certified Salesforce Instructor. Each post provides deeper insight and additional perspective around topics covered by each course module.
If you read our last post (the fourth in this series) and watched Module 4: Using Nested Components of our online course Creating Lightning Components, you learned a bit about nesting components in other components, and some of the benefits of a component-based architecture.
One of the primary benefits of using this architectural approach is that an application’s modules are loosely coupled. This simply means that there are minimal dependencies between the modules, which allows for a “plug-and-play” development approach. In the Lightning Framework, components can be easily added, removed or swapped without the risk of breaking the application. They can be built by different teams, or even purchased commercially through the AppExchange for integration in a custom application.
An event driven programming model is the key characteristic of such an architecture that allows independent components to seamlessly function together as a cohesive application. This is what we’ll focus on in Module 5: Raising and Handling Events: Part 1, and Module 6: Raising and Handling Events: Part 2.
Event Driven Programming
The Many Flavors of Lightning Events
The key to mastering event driven programming in the Lightning Component Framework is to clearly understand the different kinds of events handled by the framework, and how to design your apps to use them. There are two primary kinds of events that you will be writing code to handle:
There are two additional kinds of events: Salesforce1 events and System events. While it is important to understand what these are, and when they can be used, our course Creating Lightning Components focuses only on the first two kinds. However, we will address the others briefly in our next and last post in this blog series.
User Interface Events
User interface events are lower level events bound to elements in a component’s markup, activated typically by a user explicitly interacting with that element in the user interface. I say “typically” because it is possible to implicitly fire such an event upon load of a component during its instantiation, as was discussed in a previous post for Module 3.
Controller Action Functions
When a user interface event is fired, the associated controller action function is invoked. Three arguments are automatically passed by dependency injection to the controller’s action function handling the event:
1. Component: a reference to the instance of the Lightning Component container with the markup that fired the event.
2. Event: a reference to the instance of the event that was fired off (such as a click)
You’ll see how these are used when you watch Module 5: Raising and Handling Events: Part 1 of the course.
Custom Lightning Events
Custom Lightning Event handling is a little different than user interface event handling. You should think of custom events as notifiers for higher level business or application processes, and their prime purpose is to pass messages across components. They are fired off from one component, and typically handled in another.
There are two types of custom Lightning Events:
You’ll see how custom events are registered, fired and handled when you watch Module 5: Raising and Handling Events: Part 1 of the course.
Events Provide and Promote Loose Coupling
The benefits of custom Lightning Events, and the decoupled model they support for application development, cannot be stressed enough. They permit a development model where components don’t need to know about each other’s existence in an application.
Notifier components, those that fire the custom events, only need concern themselves with firing that event. Nothing fails or breaks if there are no components in the application registered to handle the event. The result is simply that nothing happens when the event fires.
Similarly, handler components, those designed to respond to the events, are simply there listening for it to fire. Again, if no other component fires the event, the result is simply that nothing happens.
While both the notifier and handler components are bound to the event component itself, they do not need to be bound to each other in order to work together in the application; that’s loose coupling at work! In the visual below, Component A as a notifier emits an event, and Components B and D handle it.
Event Attributes as Messages
It’s a best practice to keep the design of your Lightning Event attribute collections as light-weight as possible. Remember that the basic premise of an object oriented, event driven architecture is to facilitate sending simple messages across objects, and you will benefit in the long term if you avoid unnecessary complexity in your event structures.
Let’s Dig Back In
The eventing model is really very straightforward once you understand the different aspects of the different kinds of events, and when to use each. While it is a more complex and critical aspect of the Lightning Component Framework, it is really not very difficult to master. To see how it works, watch both Module 5: Raising and Handling Events: Part 1, and Module 6: Raising and Handling Events: Part 2.
Creating Lightning Components online course
Creating Lightning Components: Single Page Applications (1 of 6)
Creating Lightning Components: The Bundle as Scaffolding (2 of 6)
Creating Lightning Components: Action Processing and Binding Data (3 of 6)
Creating Lightning Components: Component Based Architecture (4 of 6)
Creating Lightning Components: Events and Messaging (5 of 6)
Creating Lightning Components: Wrapping It Up (6 of 6)
About the Author
Don Robins is a Force.com MVP, Certified Advanced Developer and award winning Salesforce University Certified Instructor. Since 2010, he’s been delivering the core development curriculum to hundreds of customers in both public and private workshops for Salesforce University in the US and abroad. As an independent Training Delivery Partner through his company Forcementor.com, he leads and mentors a team of certified Salesforce instructors, curriculum developers and technical authors. He found his way onto the platform as a consultant and developer in 2009, after two decades of building custom business applications with a metadata, framework-based approach. Ever since, his primary focus has been to educate developers and the business community on Salesforce1 and to evangelize the platform.