Lightning Component architecture

Before we start building Lightning Components, let's understand the architectural differences between how Lightning Components and Salesforce Classic Visualforce work.

In a traditional Classic Salesforce UI, every time a user clicks a link, an HTML page is loaded from the server. Even for small interactions, the whole web page or tab needs to be reloaded.

Lightning Experience is based on the concept of a Single-Page Application (SPA). In SPAs, once the page is loaded, for any other subsequent request of data from the server, an Ajax callout is made and the page is re-rendered with new data. The aim is to avoid the whole page refreshing.

The following diagram helps to visualize the difference between a single-page architecture and a traditional web page rendering mechanism:

The concept of web components

With web components, you can do almost anything that can be done with HTML, CSS, and JavaScript, and they can be a portable component that can be re-used easily.

Lightning Components are based on this idea, where each individual component consists of one or multiple components that use Apex, JavaScript, HTML, and CSS on top of Salesforce metadata to build a completely functional unit that can work on multiple Salesforce instances and multiple pages.

To understand how web components work, let's consider the following image. This shows how a page can have multiple components. It's also important to note that, since each of the components can consist of data from a third party, and if components from different namespaces can scrap data, it can diminish data security. Hence, Salesforce has a security mechanism known as Locker service to prevent data from being accessed.

It locks the DOM of the component and, hence, the JavaScript code from the component cannot access data from other components:

A Lightning page can have multiple components. They can be as small as a button component or can consist of components from different namespaces and different vendors. A component is a reusable unit and can be reused in Lightning Experience and Salesforce 1. To make these components interact with each other, the framework provides events. We will explore Lightning events in later chapters.

Lightning Component Bundle

A Lightning Component bundle consists of four primary sections (there are also Renderer, Design, and SVG sections apart from these four, which we will cover in upcoming chapters):

• Lightning Component Markup file (.cmp) file: This is an XML component definition and consists of HTML markup.
• CSS file (.css): This consists of CSS for the component.

• JavaScript helper and controller (.js): This consists of JavaScript code. The helper file is used to keep all the reusable code for the component. 
• Apex controller (.cls): This is not a part of the bundle, but every component that uses Salesforce data uses a server-side controller to fetch and post data to the Salesforce servers.

In the last section of this chapter, we will create a Lightning Component using the Salesforce Developer Console. In Chapter 3, Working with Lightning Component Building Blocks, we will dig deeper into each of these files and explore how to build a functional component for Lightning Experience.

Lightning Component lifecycle

A basic understanding of the sequence of steps that takes place when a Lightning Component communicates with a client and a server will help a great deal before we dive deep into how to build a Lightning Component.

The following diagram shows how a Lightning Component works between the client and server:

The key things to note from the previous diagram are as follows:

• A user action instantiates the component and an init event is raised
• The JavaScript controller function calls the helper function to perform any server-side action
• The Apex controller method is invoked from the helper function, the data is returned, and JavaScript callback functions are invoked
• The JavaScript client-side logic can be written to manipulate the DOM, set attributes, and refresh the view

MVC concepts in the Lightning Component framework

The Lightning Components framework follows the Model, View, Controller (MVC) paradigm. The component file provides the view layer, the JS controller and helper files provide the controller part, and the controller interacts with the Salesforce server via Apex. Apex connects to the Salesforce database, which acts as the Model.

The following diagram illustrates how the Lightning Component framework is based on the MVC paradigm:

Though the Lightning Component framework adopts the MVC paradigm, it is a true component-based framework first.