Introduction to Developing Salesforce Lightning Components

皆さん、こんにちは!

Hello everyone!

 

This is my first post for Hatena blog, and for this post, I will share an introduction to developing Lightning Components on Salesforce

About myself

Having at least 3 years experience creating Salesforce solutions to customers in my previous company, I joined TeamSpirit Singapore in September 2018. I am a certified Salesforce Administrator, Platform Developer and Consultant and will be more than happy to answer your questions on Salesforce development and configuration. Of course, I am constantly learning all the time, so I am open to discussions and feedback on any subject. 

Alright, enough limelighting. Let's get down to business! 

What are Lightning Components?

As you probably know, Salesforce is currently running on a new user interface called the Lightning Experience (LEX). With a "mobile-first" design approach, this new architecture utilises the latest in web technologies (e.g. web apps, JavaScript frameworks, HTML5) and allows developers to create custom Salesforce apps that run on both the web brower and the mobile device. These custom apps can be created using Lightning Components. 

f:id:ye-jerry:20181206215818p:plain

A typical Salesforce page. Some Lightning Components are highlighted in red

Lightning Components can be single-page apps or sections of an app (thus, components). This means an app (a Lightning Component) can be made up of multiple Lightning Components, each with its own self-contained function. 

Lightning Components can also interact with other Lightning Components. They can do so by directly setting the attributes of the other Lightning Component or use calling a Lightning Event so other Lightning Components can "listen" for this event and handle it. These interaction methods are more advanced topics and will not be covered in this post. 

As such, when building Lightning Components, keep in mind the design of the components and try to reuse them as much as possible.  

Architecture Overview - All in A Single Diagram

f:id:ye-jerry:20181206215337p:plain

SFLC Overview

In general, Salesforce Lightning Component (SFLC) is similar to a Model-View-Controller (MVC) model, except it has a view-controller and a model-controller. Below is a overview of some of the key elements (erm, components 😅) of SFLC:

Component Bundle

A component bundle consist of all elements and resources that make up a particular Lightning Component. These include the view, controller and helper classes. However, this does not include the Apex Controller, which means a component bundle contains all the items required for the client to render the Lightning Component. 

f:id:ye-jerry:20181207104147p:plain

A sample Lightning Component bundle in Salesforce Developer Console

View

The view of a Lightning Component is the main definition resource for a Lightning Component. It contains the design of the user interface for the component. It is a markup language file consisting of HTML5 and SFLC-specific tags (e.g. aura:component). It also contains the attributes (the instance variables) of the Lightning Component. These attributes define the data to be captured and manipulated by the component. 

f:id:ye-jerry:20181207104608p:plain

A section of a view code (sample)

Controller

In this context, the controller we are talking about here is the view-controller. These are JavaScript functions and holds the action handlers for the view of the component. For example, if a button is clicked or a data has changed in the component, these action handlers will be called to handle the events. They also define the initialisation functions when the component is first loaded (e.g. set the default values for attributes). As such, each action handler function is required to define 3 key parameters: the component (i.e. the view), the event (i.e. the HTML events) and the helper

f:id:ye-jerry:20181207104448p:plain

A section of a controller code (sample)

Helper

Helper classes help organise JavaScript functions in a Lightning Component by storing complex processing details used by action handlers. You can abstract commonly used functions into a helper function so it can be reused by multiple different action handlers. Normally, calls to server-side controller functions are usually done in helper classes. They are done using callout functions and responses are handled asynchronously

f:id:ye-jerry:20181207104638p:plain

A section of a helper code (sample)

Apex Controller

The Apex Controller acts as the model-controller and provides access to database side functions (e.g. Create, Read, Update, Delete). These functions are remote methods for Lightning Components to call and are detoned by the @AuraEnabled header in an Apex class

f:id:ye-jerry:20181207104931p:plain

A section of an Apex controller code (sample)

In summary

A Lighning Component is made up of various elements and resources which are similar to developing any other modern web applications. The only difference is that utilising the Salesforce Platform, functions and methods are optimised for the platform and as such, provides users with the most optimal user experience to Salesforce functions. 

In addition, as Lightning Components are created as a "mobile-first" design, they are compatible with the Salesforce mobile app and does not require separate apps for mobile and web; they can be created as one app that works for all! 

I hope after reading this post, you have a better understanding of Salesforce Lightning Component and feel ready to embark on the journey to create Lightning Components! 

Helpful Links

trailhead.salesforce.com

trailhead.salesforce.com

trailhead.salesforce.com