Creating Lightning Components: Component Based Architecture
Don Robins continues the series on creating Creating Lightning Components (4 of 6), discussing the benefits of loose coupling in a component based architecture.
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 third in this series) and watched Module 3: Binding to an Apex Method of our online course Creating Lightning Components, you learned a bit about actions and events, including how to bind actions and their parameters to methods on an Apex controller class using the Lightning Component Framework.
In Module 4: Using Nested Components we’ll introduce you to concepts around nesting child components in parent components, and how to pass data into a component using public attributes.
Components Are Object Oriented
Lightning Attributes, which are expressed as tags in a component’s markup, have a collection of available named attributes such as name, type, description, required and access. That last one determines the attribute’s scope, acting as an access modifier with the values public (the default), private, or global.
Lightning Attributes can have their values assigned in a variety of ways:
1. An attribute can be assigned a default value in markup.
2. An attribute’s value can be assigned upon a component’s instantiation, either by passing in a value from markup, or by using URL parameters upon the component’s load. The latter is only available for attributes of type String, but both of these examples are analogous to passing arguments as parameters into the constructor of a class upon instantiation.
Developers may create component interfaces, allowing other components to implement their shape. There are also many interfaces built into the Lightning Framework, allowing Lightning Components to easily plug-in and extend the Salesforce1 platform and capabilities. Similar to classes, a component can extend a parent component in an object oriented manner, adding additional functionality to the base attributes and methods.
Components Go Beyond Object Oriented
The overriding principle behind a component-based architectural approach is to engineer an application from a collection of functional modules that can work together in a loosely coupled manner. By communicating through a carefully designed public interface and an event messaging model, such components can provide great efficiencies in the rapid development of applications by allowing developers to hook together modular building blocks which can also be easily reused across applications.
The component approach provides reuse benefits beyond a traditional object oriented inheritance paradigm by enabling a “plug and play” model. Once a component has been written and tested, it can be made available for use and reuse in any application requiring its functionality. This is particularly beneficial for enterprise application development, as IT teams can reuse components across multiple applications or even Salesforce orgs.
Lightning Components can be easily packaged and deployed through the Salesforce AppExchange, making them available to any Salesforce customer in the ecosystem. This can provide great potential to assist in the ever present challenge to reduce time to market of custom applications.
The true value of a component-based architectural approach becomes crystal clear when a developer begins to combine components to build an application’s functional user experience.
Components provide such great potential because they are:
Reusable – a component encapsulates everything it need to function, and provides a well defined public interface that facilitates its use and reuse across multiple applications
Extensible – object oriented in nature, a component can encapsulate functionality that can be subclassed and modified for specific requirements beyond its the base design
Independent – a component can be deployed or replaced in a system with minimal dependencies, providing a robust architecture
Pluggable – one component may be swapped for another, as long as both components expose the same public interface and provide similar functionality
These key characteristics are what allow Lightning Components to support rapid development of sophisticated applications on the Salesforce1 platform. In addition, their loosely coupled nature is a great fit for parallel team development in the enterprise, where teams separated by both time and distance can each work on specific components that follow the design of a predefined public interface to support subsequent integration into a single application.
Refreshing the Display
It’s important to keep in mind that while all Lightning Components may contain a set of user interface resources, (such as markup and CSS style,) some components might not implement any presentation display at all. Many developers new to component-based architecture fail to intuit that components might contain nothing but functional logic, and in that regard are truly analogous to object oriented classes.
For example, an application might require functionality that connects with the Salesforce Streaming API. Its sole responsibility would be to subscribe to and wait for notifications on a particular channel. When it receives such a notification, it would raise an event for any listening component to process. It needs no user interface, but rather only the logic to process the API calls, notifications, and event broadcasts.
Component Architecture Example
Below is a simple visual of a Lightning Component architecture that binds to Apex action methods on the Salesforce1 platform.
This design highlights many of the characteristics of a Lightning Component architecture:
1. A special Application component which acts as an outermost container, which can be launched outside the context of the Salesforce1 app.
2. Peer components nested in the application component container.
3. The ability to nest components inside other components.
4. A loosely coupled messaging system across components, enabling them to function as a single application.
Let’s Dig Back In
This is the architecture we’ll start to explore in Module 4: Using Nested Components where we’ll learn how to nest components in other components, and provide the foundation for messaging across components that we’ll explore in subsequent modules.
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.