Creating Lightning Components: 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.

Creating Lightning Components by Salesforce University 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

It’s beneficial to understand that Lightning Components are object oriented in nature, and have similar behavior to and characteristics of classes. Components have encapsulated presentation (markup), data state (attributes), logic (JavaScript functions), and style (CSS rules).

The public interface (or shape) is represented by a component’s attributes, which are analogous to member variables of a class. Each attribute is declared with a data type for the value it will reference, and may be accessed from within the component’s markup or encapsulated JavaScript.

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.

3. Attribute values can be assigned or changed after instantiation from the component’s controller or helper JavaScript logic.

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.

Component Characteristics

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

In the last module, we showed how client-side JavaScript can make a call to a server-side Apex action method, and how that method can return data to be processed in the callback function associated with the original client-side action. If an attribute’s value is changed with JavaScript logic (such as a callback function,) any display element in the component with its value bound to that attribute will automatically refresh its display based on the attribute’s new value, (this is analogous to partial page refreshes in Visualforce.)

Non-UI Components

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.

5. An example of how components can call Apex action methods using a client-side JavaScript API that provides a service to manage efficient data transport for server-side processing.

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.

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.