The Year of Lightning

by Antigoni Tsouri

Approximately a year has passed since Salesforce announced the new Lightning experience. And what a year for Salesforce! At first I thought ‘this is going to take a while, there’s going to be a learning curve, probably known bugs to deal with’, we tentatively started switching on the New Lightning Experience to play around with the new User Interface. In a short while we tested some visualforce pages embedded in the new Salesforce application. Finally, this summer we made the leap to building the first Lightning components and Lightning application.

Lightning Components framework is a set of out-of-the-box components build on the open source Aura framework. Developers can utilise Aura to build their own custom components and extend framework. The key here is that Lightning Components are client-side based. Lightning Components Framework has an event driven architecture and relies mostly on Javascript on the client side to manage the UI and application data. Hence it is much better performance wise as opposed to Salesforce classic technologies that rely heavily on the server. You can find more information by visiting these links:

Lightning Components Framework: https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/intro_framework.htm

Open source Aura Framework: http://documentation.auraframework.org/auradocs

One of my favourite series as a child was ‘The Flash’. He could miraculously find himself from his home dressed in pyjamas, down the street in front of a shop window within seconds. When I built my first Lightning app this year, the images from ‘The Flash’ running around with the speed of light immediately came to my mind. Three words: fast, simple, beautiful. No wonder they named it Lightning.

The Lightning components and applications are easy to code, convenient to assemble with other components, reusable and flexible. They are working everywhere with the need for minimal to zero adjustments. Even the MavensMate IDE has a Lightning plugin that can save your component’s code from local directories to your sandbox in the cloud within 6 seconds. By comparison the traditional Salesforce code component — like an Apex class or a Visualforce Page — would take approximately 10 seconds to be saved in your sandbox.

The Lightning application we built is based on the concept of a licenced territory on an Opportunity record. By ‘Licenced Territory’ we mean a set of regions & countries connected with the opportunity. It can be either one or multiple regions, one or multiple countries or both of the previous at the same time.

In other words once a user lands on the app, they should be able to select any possible permutation of including / excluding regions and countries.

We could have build this app with Visualforce. However that would involve several stages of pages’ re-rendering and waiting times in between these stages. The several different pages subsequently means a clunky user interface with ‘Previous’ and ‘Next’ buttons and annoying load times for the end users. Furthermore it means a lot more code than an application that holds most of the navigation logic on the client side. Too many calls to the server which is expensive for an application, performance implications and the story goes on…

Let’s see what we actually created :

• One standalone Lightning component for managing regions (including and excluding).
• A second component — also standalone — for searching countries.
• And one to rule them all — a parent component that nests two independent components.

The parent component’s job is simply to list the results of the combinations users are selecting. So, if our user chooses to include or exclude a region, the parent component lists all the countries under that region. Similarly, if a user wants to deselect a region, the countries that belong to the region, will automatically disappear from the screen. Lastly, the user can search and list a country that doesn’t belong to any of the selected regions. All on the same page. Dynamically.

Communication between components in Salesforce happens through events. A component produces a Lightning event upon a user interaction. A component can also produce an event if any of it’s attributes change. If there is any component that’s listening to this event it can action on it. If there’s not any listeners out there, that’s still fine, nothing will break.

In our case, the independent components are producing events which are holding this information ‘Hey guys, I’ve got X region that’s been selected!’ or ‘Hello world — I’ve got Y region that’s been unselected !’ or ‘Hey, this extra Z country has also been included !’. Our parent component tracks such events and takes action, e.g. ‘Ok, let’s see which countries belong to X region that’s been selected as included — I will list them here’.

To demonstrate how simple this is for code lovers, here are some key parts of the lightning app to bear in mind.

User Interface for searching any country and checking it to include it

Let’s concentrate on the ‘ui: inputCheckbox’ which is how the user will select countries. The method ‘handleCountryChanged’ is then called, on the client side.

Javascript controller (or else client side controller) for the same component

With the below method the client is simply tracking down which part of the UI has called the method. It then produces an event that contains the selected Country and two boolean values — included & excluded.

Parent component user interface and javascript controller that listen and handle the event.

All the parent component has to do is to be able to listen to specific events and process them using a specific method. It can do this using the following code:

<aura:handler name=”countryChanged” event=”c:CountryCheckboxChange” action=”{!c.handleCountryChanged}”/>.

The method ‘handleCountryChanged’ can then manipulate something in the User Interface or even call a server-side (apex controller) method to perform some data dml or retrieve data.

It’s worth noting that the apex class serving a Lightning component is very simple, defined purely on a set of @AuraEnabled methods with the sole purpose of retrieving data or manipulating data in a database. Clean architecture with segregated and defined responsibilities. An industry-standard wide model: User interface, client side as a mediator between UI and backend and the backend / server.

From my point of view, Salesforce’s plans are crystal clear before they even announce their next move. The aim is maximum reusability and flexibility of all Salesforce components, and make releases to Production environments as fast as mainstream languages. With the whole idea of componentization, I would not be surprised if they were to announce that you can tie a simple custom field, in other words a table column, to a Lightning component and customize it to your client’s needs with minimum effort. Especially looking at the pace they are moving, I would not be at all surprised if they announced such things in the near future.