Chapter 9. Lightning

Lightning is a rich client side framework for developing device agnostic and responsive user experiences as well as supporting mobile, tablet and desktop. Unlike Visualforce it was built from the ground up with today's multi-device rich client demands in mind. It is used by Salesforce themselves and is also available to developers to build their own standalone or platform integrated UIs. Using Lightning Out developers can also integrate UIs built with Lightning into external sites and applications. An emphasis on componentization is at the heart of its architecture, and plays a key part in providing a means to implement reuse, separation of concerns and extensibility.

This chapter provides an architectural overview of the Lightning component architecture, while contrasting it with its predecessor Visualforce. New Lightning Components called Race Calendar, Race Results, Race Standings and Race Setup will allow us to explore and development process and styling using Lightning...

Building a basic Lightning user interface

Before we dive into the more complex components included in the sample code for the FormulaForce application, let's first create a simple Lightning Application to better understand the architecture of Lightning. Think of a Lightning Application as a container for your UI, essentially your HTML markup. Containers are effectively things you can navigate to in the browser, they get their own URL based on the name you give them.

Note

As we will explore later in the chapter, Lightning Experience and Salesforce1 Mobile are also containers built by Salesforce in the same way as the example that follows.

If you want to follow along with the next few steps, ensure you have installed the Force.com IDE with support for Lightning Components. We will be taking a closer look at the Force.com IDE features around Lightning later in this chapter.

Follow these steps to create your first Lightning Application:

1. Ensure that you are using a Developer Edition org with My Domain...

Lightning architecture

In this section, we will discuss key layers of the Lightning architecture that will allow you to have a better framework of understanding as you go deeper.

A key aspect that took me by surprise at first is the need to write client-side controllers in JavaScript. This can be particularly puzzling at first if you are Visualforce developer, but is vital part of being a Lightning developer and is a reflection of its client side architecture. As we saw in the previous chapter, Apex server side controllers still play a part but are mainly for accessing your backend Apex Services and Selectors.

In general, Lightning development is much more componentized. In terms of how the UI is designed and how the code is factored, the two are much more aligned, making it easier to maintain and navigate code. This also gives a much greater emphasis on separation of concerns within the UI tier.

Containers

As we saw in the previous section, we created a basic container called myapp using a...

FormulaForce Lightning Components

In designing the Lightning Components for the FormulaForce sample application contained in this book, I wanted to try to demonstrate some key integration points within the Salesforce UIs, while also ensuring the use cases fit with the application domain.

I focused on Lightning Experience and Salesforce1 Mobile. It is also good practice to think platform-first, before embarking on any extensive development. I started with the following use cases and then devised a set of components to deliver the functionality.

• Race Overview: while the standalone Lightning Application we looked at earlier was a good means to get started with the components, it's not a Salesforce integrated solution. What I wanted to do was integrate the Lightning Experience Home Page, through the Lightning App Builder customization tool. Not only to show the overall standings (leaderboard), but to allow users to filter information through the race calendar to show the results from each completed...

Making components customizable

The components included in this chapter will appear in Lightning App Builder and are thus available for the developer and consumers of the package to drag and drop them onto pages. Because they are global they can also use them in their own component code:

This is due to the following aspects:

• The access attribute on the components is set to global.

• They implement applicable flexipage and force interfaces.

• Though not required, the .design files specify a component label:

  <design:component label="Race Calendar">
  </design:component>

• The .svg file for the c:CheckCompliance component defines a custom icon that is displayed next to the component in the Lightning App Builder.

• Though not required, the Race Result component also includes additional markup to indicate to Lightning App Builder, the component is only relevant to the Race__c custom object:

  <design:component label="Race Results">
  <sfdc:objects>
  <sfdc:object>Race__c</sfdc:object...

Integrating with Lightning Experience

The following screenshots highlight the various points at which the components have now been integrated with Lightning Experience. These components are still available to the Race Overview standalone app we started this chapter with, though additional interfaces and events now support more advanced containers through Lightning App Builder.

This screenshot shows the Race Results and Race Standing components on the Home page, with the Race Calendar component accessible via the Utility Bar. The race results are updated as the user selects races from the Race Calendar:

Tip

The Utility Bar is defined using a Lightning Page (or FlexiPage as it's known in Metadata form). The sample code in this chapter included such a page called RaceManagementUtilityBar in the /flexipages folder. This page is referenced in the Race Management app metadata (in the /apps folder).

This screenshot shows the Race Setup component appearing as a result of the user clicking the Add Drivers...

Lightning Out and Visualforce

Lightning Out is a JavaScript library that can be imported into regular HTML pages, such as Visualforce pages and other websites or other containers such as Google Apps. Once imported it exposes an API that allows the page developer to instantiate a Lightning Component and inject it into a given HTML element on that page. The host page must provide a Salesforce Session or oAuth token to allow this to happen in a secure way.

The process of using Lightning Out for Visualforce pages is simplified through the use of the apex:includeLightning component on the page which loads the JavaScript library and handles authentication. Call the $Lightning.use global method to begin the bootstrapping process to load the component onto the page.

Tip

Using Lightning Components on a Visualforce page does allow you to consider ways to develop new areas of your solution with Lightning while still delivering a Salesforce Classic user experience for customers that still require it.

For...

Integrating with communities

Lightning Community is another container for your Lightning Components; as such existing components are likely already close to being able to exist within it and the Lightning Community Builder tool. The most basic requirement is that your components implement the forceCommunity:availableForAllPageTypes interface.

The same considerations to specify a component .design file as described in the earlier section also apply so that the components appear correctly in the Lightning Community Builder tool, notably making the components access level global.

It is also possible to customize the Lightning Community container through components implementing interfaces that provide a custom theme layout, profile header, search and post publisher components and content layouts. Consult the interfaces within the forceCommunity namespace for more details.

Testing

At the time of writing there is no Salesforce provided test framework for Lightning components as there is for Apex. Salesforce has not officially commented, but it is likely that they will include the Aura test framework that exists today in the open source project in a future release of the Force.com platform (http://documentation.auraframework.org/test/runner.app).

Meanwhile I recommend you review existing browser testing tools.

Updating the FormulaForce package

As with previous chapters, check that all new components have been added to the FormulaForce package and upload it. Due to the inclusion of the Utility Bar the package now requires My Domain to be configured in orgs for installation to complete. While My Domain offers some increased security benefits for customers, it does come with the implications that need careful consideration. Consult with your customer base before making this dependency on your package.

Summary

In this chapter, you have understood the high level architecture of the Lightning framework, both from a the perspective of a standalone page to integrating Lightning Components within Lightning Experience and Salesforce1 Mobile.

Lightning Experience is now more extensible than the original Salesforce Classic user interface. There are more options to consider before deciding your only option is to start building entirely new from the ground up page level experiences. Thinking about these integration capabilities as you consider your user experience requirements along with how aligning component thinking between developers and UX designers is a key to embracing this new of building applications on Salesforce.

The need for Separation of Concerns and good coding practices is now as important at the client tier as it is at the backend. It is also more important to monitor your architecture for encapsulation of and containment of your business logic. This should still remain firmly at...